O.O*_*O.O 21 index sql-server-2008 sql-server ssms
我经常使用 SSMS 来测试我的慢速存储过程是否缺少索引。每当我看到“缺少索引（影响 xxx）”时，我的下意识反应就是创建新索引。据我所知，这每次都会导致更快的查询。
为什么我不应该继续这样做？
JNK*_*JNK 27
很多原因。
我能想到的最大问题之一是缺失的索引 DMV 不考虑现有索引。
例子：
你有一张桌子ColA, ColB, ColC。
目前，您在 上有一个索引ColA。缺失的索引 DMV 会建议您在(ColA, ColB). 这可能是正确的，但明智的做法是ColB在现有索引上添加第二个键。否则，您将有重复的覆盖范围并浪费空间和开销。
同样，如果您有一个关于 的索引ColB INCLUDE (ColA)，它可能会建议一个关于 的索引ColB INCLUDE (ColC)。同样，聪明的做法是添加ColC到现有索引中的包含列表中。
建议的索引具有极其狭窄的视图 - 它们仅查看单个查询或单个查询中的单个操作。他们不考虑已经存在的内容或您的其他查询模式。
您仍然需要一个有思想的人来分析整体索引策略并确保您的索引结构高效且有凝聚力。
如果仅仅添加所有建议的索引没有问题，那么甚至不需要建议它们——它们会自动实现。
小智 8
我建议谨慎使用这种调优技术，因为我发现查询计划弹出的缺失索引建议始终不可靠，因为查询和数据库模式变得越来越复杂。根据我的经验，这是由于多种原因造成的：
1) 除了最简单的查询/最明显的索引之外，所有的“百分比改进”都可能相差甚远，毕竟它只是一个估计值，并不是从查询运行时产生的实际成本或实际行数得出的。我已经看到在实施建议的索引后查询成本上升，或者它甚至没有被使用并且计划保持不变。
2) 查询计划本身不是最优的，要么是由于查询的构造（连接和 where 子句未优化等），要么是由于缺少/过时的统计信息而导致行数估计不正确。对一个极其糟糕的查询计划进行索引通常充其量只是一种创可贴的解决方案，只会逐步提高性能。
3) 你可能看不到全貌。在仅使用图形计划而不查看 XML 以查看是否建议了多个缺失索引时尤其如此。图形计划中第一个显示的不一定是对查询影响最大的那个。
4) 我也遇到过很多在修改现有索引时建议新索引的例子。关于这一点，请参阅此处的其他答案，它们是正确的，无需我进一步详细说明。
在处理不熟悉的查询/环境时，我只使用缺失的索引建议作为起点，以查看哪里可以更深入地查看。查看计划中的运算符（主要是搜索/扫描/连接）并检查工具提示或属性窗口以查看涉及哪些列并使用它来确定索引候选以进行改进测试，我获得了更好的结果。