SQL Server 2008中的羣集索引

我有一個包含複合主鍵的表。它創建聚集索引。如果我在WHERE子句中使用該複合主鍵中的幾列，該索引是否仍然有效？或者我必須根據WHERE中使用的列創建新索引？任何幫助，將不勝感激。SQL Server 2008中的羣集索引

2011-05-19 gmail user

任何索引（無論是否爲聚簇）只對查詢有用，只要它的定義中最左邊的列都是WHERE子句的一部分即可。

如果您有(Col1,Col2,Col3)索引，那麼這個指數可以爲所有使用3列，或Col2和Col1，或者只是Col1 WHERE子句有用。但只要Col1不是包含在搜索中，索引就沒用了。

2011-05-19 14:28:28

這可能是一個COL1，COL3搜索，但情況因人而異有用。我想添加那麼WHERE子句順序無關緊要，所以col1，col2與col2相同，col1 * only *在WHERE子句中儘管... +1也是 – gbn 2011-05-19 14:29:48

非常感謝您的所有答案。很好的幫助。順便說一句，YMMV是什麼？ – 2011-05-19 15:08:59

@gmail用戶 - 您的里程可能會有所不同 - 這是一種表明您提供的建議在您的特定情況/環境中可能正確也可能不正確的方式，因此建議您在依賴真實數據/查詢之前對其進行測試就像是真實的。 – 2011-05-19 15:48:33

如果有可能，我儘量避免組合鍵 - 特別是主鍵。另外：如果您有複合鍵，則只有在使用最左邊的n列時纔有效。如果您的組合鍵中的第三個位置有一列，並且您的搜索僅在該第三列上有WHERE，則索引將無法使用。

聚類鍵理想情況下是一個小的，穩定的，唯一且不斷增長的列 - INT或BIGINT作爲默認選項。不要超載您的羣集密鑰！不要過於寬泛，並且儘量避免使用不同大小的列（如VARCHAR - 它們會帶來額外開銷）

還有一個問題需要考慮：表中的集羣鍵將被添加到每個列以及桌面上每個非聚集索引中的每個條目 - 因此您確實希望確保它儘可能小。通常情況下，具有超過250億行的INT應該足以滿足絕大多數表的要求 - 並且與GUID作爲集羣密鑰相比，您可以爲磁盤和服務器內存節省數百兆的存儲空間。

還有一些值得思考的東西 - 金伯利特里普的優秀作品 - 讀它，再讀一遍，消化它！這真是SQL Server索引福音書。

2011-05-19 14:29:52

回答