当我查看特定查询的执行计划时,发现77%的成本在于聚集索引搜索。使用聚集索引是否意味着我不会因为输出的列而遇到性能问题?是否最好创建一个包括所有输出列的非聚集版本?更新: 聚集索引使用复合键。不确定这是否有差异。
在非聚集索引中使用包括列的原因是为了避免对聚集数据进行“书签查找”。问题是,如果SQL Server 理论上可以使用特定的非聚集索引,但优化器估计会有“太多”的书签查找,则该索引将被忽略。但是,如果所有选定的列都可以直接从索引中访问,则不需要进行书签查找。在您的情况下,通过“聚集索引查找”访问数据非常有前途。很难提高其性能。包括所有选定列的非聚集索引可能会稍微快一些,但仅因为原始数据略少。(但不要忘记增加插入/更新时间的成本。)但是,您应该检查细节... 如果您正在使用组合键,并且查找实际上仅限于键的开头,则您可能就没有那么幸运了。您可能会发现查找仅缩小到500,000行,然后基于其他标准搜索该行。在这种情况下,请尝试使用一些非聚集索引。 聚集索引查找本身可能很好;但是,如果由于某些其他方面效率低下而返回太多行而进行100,000次查询,则通过改善聚集索引查找的性能不会获得多少收益。 最后,为了详细说明davek的评论:“成本是相对的”。仅因为聚集索引占查询成本的77%并不意味着存在问题。可能编写一个微不足道的单表查询,返回单个行和聚集索引查找成本为100%。(但是当然,作为唯一的“工作”,它将是100%的工作...而且100%的瞬间仍然是瞬间。所以:“不要担心;保持愉快!”
您已经有了一个搜索,因此好处可能很小。 不过您可以尝试一下。选项: 第二个非聚集索引,保留原始 将聚集索引移动到另一列 还有其他好的聚集候选项吗?请注意,您始终需要一个唯一的聚集索引(因为唯一标识符 + 这里是SO + 这里)。当然,您的PK是什么?