SQL Server 2008 R2 缺少索引
我正在對數據庫執行索引維護。我已經執行了使用 DMV 提供 SQL Server 認為應該創建的索引列表的 SQL 腳本。我不是因為索引被列為缺失而創建索引。我的問題，為什麼主鍵列會被列為缺失索引？該表按主鍵順序排列，對嗎？為什麼 SQL Server 會認為應該在主鍵上創建非聚集索引？
提前致謝。
預設情況下，SQL Server 中的主鍵也是集群鍵- 數據按表中的集群鍵物理排序。
因此，如果列出了這個主鍵，可能是因為它是一個非聚集的主鍵——你必須明確地做這件事——但這完全有可能。
主鍵是一個邏輯結構——它的工作是確保表中的每一行都可以唯一且可靠地標識。它對錶格的物理結構沒有任何影響。
聚集鍵（以及聚集索引）決定了 SQL Server 表中數據的物理順序。預設情況下，表的主鍵是集群鍵——但它不是必須的——你可以為主鍵和集群鍵設置兩組完全獨立的列。
但除了所有這些事情：辨識缺失索引的 DMV 並不完美 -一定要對他們的建議持保留態度！不要盲目地實施 DMV 推薦的所有東西——有時它會推薦已經存在的東西，或者它的一些建議甚至適得其反！不要盲目相信它——它是一個幫助工具——但它並不完美！
正如 Marc 所提到的，主鍵是一個邏輯結構，它本身並不表示集群鍵。我不會在我的回答中重複該資訊，但如果您想更深入地解釋聚集索引和非聚集索引背後的結構之間的差異，我有一個影片可能對您有所幫助。
現在，失去的索引 DMV 完全有可能（正確地）告訴您，僅在主鍵列上的附加索引可能有助於查詢。為什麼？
如果查詢需要掃描表中的所有PK 列值（並且僅此），則掃描聚集索引或另一個非聚集索引以獲取該資訊的成本更高（可能更高）*。*僅包含 PK 列的窄索引會比這更有效，特別是如果在利用鍵順序的地方涉及合併連接。
因此，缺失索引算法開始發揮作用，並建議僅在它需要的列上使用較窄的索引會有所幫助。
解決該建議的操作過程取決於正在執行的查詢以及您擁有的其他索引，並且進入該問題超出了此問題的範圍，因此我將其留在那裡。
缺少的索引 DMV 沒有太大幫助的地方是，當它建議與您已有的索引匹配的稍微窄一些的索引時。在某些情況下，還會錯誤地建議已存在的索引的精確副本。由於這些原因，您可以通過自己的大腦和判斷過濾 DMV 輸出，而不是自動創建它建議的索引。