SQL索引問題：爲什麼SQL Server更喜歡這個非集羣索引到一個集羣？

我有以下查詢：SQL索引問題：爲什麼SQL Server更喜歡這個非集羣索引到一個集羣？

SELECT 
    COUNT(*) 
FROM 
    FirstTable ft 
     INNER JOIN SecondTable st ON ft.STID = st.STID

正如您可以猜到，「STID」是「SecondTable」 ......和「FirstTable」主鍵將有一個指向第二個表。下面是我的指標：

FirstTable：上欄「STID」

SecondTable非聚集索引：CLUSTERED PRIMARY KEY INDEX的「STID」

上面的查詢給我的19.90子樹的成本和花費2秒。

運行該查詢的數據庫調整顧問後，他們建議使與我在第二張表上的索引非常相似......但是非集羣索引。所以我嘗試了這些結果。

FirstTable：上欄「STID」

SecondTable非聚集索引：在「STID」 NONCLUSTERED INDEX

現在，上面的查詢給我的10.97子樹的成本和花費<1秒！

這100％破碎了我的大腦......爲什麼在這種情況下，NONCLUSTERED索引的執行速度比CLUSTERED索引更快？

來源

2010-03-03 Timothy Khouri

因爲您的查詢不從表中檢索任何實際記錄，所以它只是計數。

對於非聚簇索引，它只是連接兩個使用最可能的MERGE JOIN的索引（大小比表小）。

對於聚集索引，它必須加入表和非聚集索引。表格較大，需要更多時間來遍歷它。

如果發出這樣的詢問：

SELECT SUM(first_table_field + second_table_field) 
FROM FirstTable ft 
INNER JOIN 
     SecondTable st 
ON  ft.STID = st.STID

以檢索實際值，你會看到集羣的好處。

來源

2010-03-03 12:13:41 Quassnoi

太快了！ - 這正是我正在尋找的明確，合乎邏輯的答案。 - 當然，這不是我的*真實*查詢，但它確實有助於我真正的查詢（不使用該表中的列，而只是將它用於內部聯接/過濾） - Thx！ – 2010-03-03 12:18:50

@Quassnoi：對不起，這個答案對我來說沒有意義。你說：「有了聚集索引，它必須加入表格」。聚集索引是一個索引。原始查詢並不真正檢索任何列，因此它必須匹配鍵值，即它只需要掃描索引頁。如果您查看這些圖片，請https://technet.microsoft.com/en-us/library/ms177443%28v=sql.105%29.aspx和https://technet.microsoft.com/en-us/library /ms177484%28v=sql.105%29.aspx，區別在於，在聚簇索引中，葉節點中有數據，但查詢不需要轉到葉級別。 – costa 2015-03-23 18:41:57

@quassnoi：繼續......除非使用*對查詢優化器做了某些事情，並且最好使用count（1）來代替。根據我在SQL Server上的經驗，特別是2008年和2008年R2，有時它會做這些你永遠不會想到的死腦筋的事情。 – costa 2015-03-23 18:46:37

SQL索引問題：爲什麼SQL Server更喜歡這個非集羣索引到一個集羣？

回答

相關問題