SQL Server中未被执行计划使用的索引为何会拖慢查询？

这事儿确实有点反直觉，我来给你捋捋背后的门道——核心都绕不开SQL Server查询优化器的成本估算逻辑和统计信息的影响：

• 统计信息“误导”了优化器：哪怕这个索引没被最终选用，优化器在生成执行计划时，会把所有相关索引的统计数据都拉进来计算成本。如果这个索引的统计信息过时、直方图有偏差，或者它的存在让优化器对其他索引的预估行数/IO成本算错了，就会导致优化器选了一条看起来成本低但实际跑起来巨慢的路径。移除这个索引后，优化器只盯着剩下的有效索引评估，反而选到了更优的执行计划。

• 索引过多增加优化器的“决策负担”：当表上的索引数量太多时，优化器需要遍历更多的索引组合来寻找“最优计划”，虽然大多数时候这点开销可以忽略，但如果你的查询本身比较复杂（比如多表关联、复杂过滤条件），加上统计信息的小误差，可能会让优化器在决策时“走偏”，选了一个次优计划。

• 强制索引时的“跳过成本评估”效应：你用查询提示强制选这个索引时，相当于直接告诉优化器“别算了，就用这个”。而这个索引的结构其实刚好完美适配你的查询——比如它是个覆盖索引（包含了查询需要的所有列，不用回表），或者索引键列的顺序刚好匹配你的过滤、排序需求。只是优化器之前因为统计信息错误（比如低估了回表的IO开销，或者高估了这个索引的扫描成本），没选中它，强制之后反而走了最快的路径。

几个验证方向帮你确认： #

1. 更新统计信息：执行 UPDATE STATISTICS 你的表名 WITH FULLSCAN，然后再跑默认查询，看看执行计划和耗时有没有变化。
2. 对比执行计划：重点看移除索引前后，优化器选择的运算符（比如是表扫描、索引扫描还是查找），以及预估行数和实际行数的偏差——如果偏差超过20%，大概率是统计信息的锅。
3. 检查索引结构：看看它的键列是不是你的查询过滤/排序用到的列，有没有包含查询需要的所有输出列（也就是覆盖索引），如果是的话，优化器没选它基本就是成本估算错误导致的。

内容的提问来源于stack exchange，提问作者Ron Isaac