爲什麼這個查詢中沒有使用聚集索引？

我有如下表：爲什麼這個查詢中沒有使用聚集索引？

CREATE TABLE [Cache].[Marker](
    [ID] [int] NOT NULL, 
    [SubID] [varchar](15) NOT NULL, 
    [ReadTime] [datetime] NOT NULL, 
    [EquipmentID] [varchar](25) NULL, 
    [Sequence] [int] NULL 
) ON [PRIMARY]

用下面聚集索引：

CREATE UNIQUE CLUSTERED INDEX [IX_Marker_EquipmentID_ReadTime_SubID] ON [Cache].[Marker] 
(
    [EquipmentID] ASC, 
    [ReadTime] ASC, 
    [SubID] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
GO

而這個查詢：

Declare @EquipmentId nvarchar(50) 

Set @EquipmentId = 'KLM52B-MARKER' 

SELECT TOP 1 
    cr.C44DistId, 
    cr.C473RightLotId 
From Cache.Marker m 
    INNER JOIN Cache.vwCoaterRecipe AS cr ON cr.MarkerId = m.ID 
Where m.EquipmentID = @EquipmentId And m.ReadTime >= '3/1/2013' 
ORDER BY m.Id desc

這裏是正在生成的查詢計劃：

enter image description here

我的問題是這樣的。爲什麼Cache.Marker表上的聚簇索引不是用於查找而是在另一個索引上進行掃描？此外，SSMS查詢分析器建議我在包含ID和EquipmentID列的Marker.ReadTime上添加一個索引。

Cache.Marker表中大約有1M行。

來源

2013-03-07 Randy Minder

@pst - 我不跟着你。 – 2013-03-07 20:43:38

你可以在查詢中用'KLM52B-MARKER'代替@EquipmentID嗎？你沒有得到所需的索引變量？ – bobs 2013-03-07 20:49:01

爲什麼人們總是認爲聚集索引始終是滿足任何查詢的最快方法？ – 2013-03-07 20:59:31

你有多少個獨特的設備ID？這可能是決定日期是一個更好的第一次查找（可能是錯誤的）。您可以強制它使用您的索引，儘管WITH(INDEX())聲明。 FORCESEEK也可以提供幫助。我強烈建議這樣做，因爲隨着數據庫規模擴大，索引行爲是可預測的。

SELECT TOP 1 
    cr.C44DistId, 
    cr.C473RightLotId 
From Cache.Marker m 
    WITH (INDEX(IX_Marker_EquipmentID_ReadTime_SubID), FORCESEEK) 
    INNER JOIN Cache.vwCoaterRecipe AS cr 
    ON cr.MarkerId = m.ID 
Where m.EquipmentID = @EquipmentId And m.ReadTime >= '3/1/2013' 
ORDER BY m.Id desc

來源

2013-03-07 20:44:35 ThinkingStiff

大致有24個獨特的設備ID值。 – 2013-03-07 20:48:46

hmm，24個獨特的設備ID值可能表明選擇性低。 – bobs 2013-03-07 20:49:58

@RandyMinder只有24個不同的ID，SQL Server已經決定它不是很有選擇性（一百萬行）。感覺使用日期是一個更好的選擇。同時測試。這往往是錯誤的。 – ThinkingStiff 2013-03-07 20:50:01

爲什麼這個查詢中沒有使用聚集索引？

回答

相關問題