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

Question

当我查看特定查询的执行计划时，我发现我的成本的77％是在Clustered Index搜索中。

我使用聚簇索引的事实是否意味着由于我输出的列而导致性能问题无法解决？

为我创建一个非集群版本并包含所有正在输出的列会不会更好？

更新： 聚簇索引使用复合键。不确定这是否有所作为。

Answer 1

您在非聚集索引上使用包含列的原因是为了避免对群集数据进行“书签查找”。问题是，如果SQL Server 理论上可以使用特定的非聚集索引，但优化器估计会有“太多”书签查找，那么所述索引将被忽略。但是，如果可以直接从索引访问所有选定的列，则不需要书签查找。

在您的情况下，您通过“聚簇索引查找”访问数据的事实是非常有希望的。改善其表现将非常困难。包含所有选定列的非聚集索引可能略微更快，但仅因为原始数据少一点。 （但不要忘记增加插入/更新时间的成本。）

但是，您应该查看详细信息......

• 如果您正在使用复合键，并且搜索实际上只在键的开头，那么您可能不会那么幸运。您可能会发现搜索范围仅缩小到500,000行，然后根据其他条件进行搜索。在这种情况下，试验一些非聚集索引。
• 聚集索引寻求本身可能没问题;但是如果在你的查询中完成了100,000次，因为其他一些方面没有效率地返回太多行 - 那么你就不会通过提高聚簇索引搜索的性能来获得太多收益。

最后，详细说明戴维的评论：“成本是相对的”。仅仅因为群集占查询成本的77％并不意味着存在问题。可以编写一个简单的1表查询，该查询返回一个sinlge行，并且聚集索引的搜索成本为100％。 （但当然，作为唯一的“工作”，将 100％的工作......并且100％的瞬间仍然是即时。
所以：“别担心，快乐！”

Answer 2

你已经有了寻求，所以收益可能很小。

你可以尝试一下。选项：

• 第二个非聚集索引，保留原文
• 将聚集索引移动到另一列

还有其他优秀的群集候选人吗？请注意，您始终需要一个唯一的聚簇索引（因为uniquifiers + here SO + here）。当然，请问你的PK是什么？

Answer 3

这取决于你谈论的列数，如果一对是，非聚集索引将表现更好，如果你选择了大多数列聚簇索引更好。