最好使用包含列的Clustered索引或Non-Clustered索引？

Question

當我查看特定查詢的執行計划時，我發現我的成本的77％是在Clustered Index搜索中。

我使用聚簇索引的事實是否意味着由於我輸出的列而導致性能問題？

對我來說，創建一個非集群版本並包含所有正在輸出的列會更好嗎？

更新：聚集索引使用復合鍵。 不確定這是否有所作為。

Answer 1

您在非聚集索引上使用包含列的原因是為了避免對群集數據進行“書簽查找”。 問題是，如果SQL Server 理論上可以使用特定的非聚集索引，但優化器估計會有“太多”書簽查找，那么所述索引將被忽略。 但是，如果可以直接從索引訪問所有選定的列，則不需要書簽查找。

在您的情況下，您通過“聚簇索引查找”訪問數據這一事實非常有希望。 改善其表現將非常困難。 包含所有選定列的非聚集索引可能稍微快一點，但僅僅因為原始數據稍微少一些。 （ 但不要忘記增加插入/更新時間的成本 。）

但是，你應該檢查細節......

• 如果您正在使用復合鍵，並且搜索實際上僅在鍵的開頭，那么您可能不會那么幸運。 您可能會發現搜索范圍僅縮小到500,000行，然后根據其他條件進行搜索。 在這種情況下，試驗一些非聚集索引。
• 聚集索引尋求本身可能沒問題; 但如果在查詢中完成100,000次，因為某些其他方面無效地返回太多行 - 那么通過提高聚簇索引查找的性能，您將無法獲得太多收益。

最后，詳細闡述戴維的評論：“成本是相對的”。 僅僅因為群集占查詢成本的77％並不意味着存在問題。 可以編寫一個簡單的1表查詢，該查詢返回一個sinlge行，並且聚集索引的搜索成本為100％。 （但當然，作為唯一的“工作”，它將是 100％的工作......而且100％的瞬間仍然是即時的 。
所以：“別擔心，快樂！”

Answer 2

你已經有了尋求，所以收益可能微乎其微。

你可以嘗試一下。 選項：

• 第二個非聚集索引，保持原始
• 將聚集索引移動到另一列

還有其他好的集群候選人嗎？ 注意，你總是需要一個獨特的聚簇索引（因為unquifiers + 這里SO + 這里 ）。 當然，請問你的PK是什么？

Answer 3

這取決於你談論的列數，如果是一對，那么非聚集索引將表現更好，如果你選擇了大多數列聚簇索引更好。