SQL Server 2016：存在覆盖索引仍高扫描计数，请求性能优化

看起来你已经做了不少基础优化工作（覆盖索引、统计信息更新、碎片整理），但Feedback和ApplicationUser的聚集索引扫描还是拖慢了查询速度，我从几个实战角度给你一些排查和优化方向：

1. 先确认覆盖索引是不是真的“覆盖”了所有需求 #

• 赶紧核对你的覆盖索引包含的列，和查询里所有用到的列做对比——包括SELECT列表、JOIN条件、WHERE过滤、ORDER BY/GROUP BY的列，哪怕缺了一个小列，SQL Server都可能放弃索引，转而走聚集索引扫描去补数据。
• 打开执行计划，查看聚集索引扫描节点的「输出列表」，把这些列和你的覆盖索引列一一对照，大概率能找到遗漏的列。比如如果查询里取了ApplicationUser.LastLoginTime但索引没包含它，扫描就不可避免。

2. 排查谓词的“可搜索性”（SARGability） #

• 检查涉及这两个表的WHERE/JOIN条件，有没有写索引失效的写法：
  • 比如对列做函数运算：DATEDIFF(day, CreateDate, GETDATE()) < 30，这种写法会让SQL Server没法用索引，只能全表扫。改成CreateDate > DATEADD(day, -30, GETDATE())就没问题了。
  • 还有隐式转换的坑：比如Feedback.UserId是INT，而JOIN的参数是VARCHAR，SQL Server会自动转换列类型，直接导致索引失效。务必确保JOIN两边的数据类型完全一致。
  • 不等于（<>）、NOT IN、多条件OR（非同一列的OR）这类操作，也容易触发扫描，能改的尽量改成等价的IN/AND组合。

3. 深挖执行计划的细节 #

• 你提到执行计划开头是USE [BO...]，建议把聚集索引扫描节点的属性拉出来看：
  • 预估行数和实际行数差多少？如果差好几倍，哪怕更新了统计信息，可能也是采样率不够——试试UPDATE STATISTICS [Feedback] WITH FULLSCAN和UPDATE STATISTICS [ApplicationUser] WITH FULLSCAN强制全量更新，这对大表特别有用。
  • 看看执行计划里的「扫描理由」，是SQL Server觉得扫描比索引查找更划算（比如要返回表中70%以上的数据），还是它认为索引成本太高？如果是后者，那可能是索引本身的设计有问题，或者统计信息不准导致成本估算错误。

4. 排查参数嗅探问题 #

• SSRS调用的存储过程很容易踩参数嗅探的坑：第一次执行时用的参数生成的执行计划，后续用差异大的参数时就会失效，导致低效扫描。
• 可以试试这几个方案：
  • 在存储过程的查询末尾加OPTION (RECOMPILE)，让每次执行都生成适配当前参数的计划（如果调用频率不是极高，这个方案最直接）。
  • 用OPTIMIZE FOR UNKNOWN让SQL Server基于统计信息的平均情况生成计划，避免被极端参数带偏。
  • 如果存储过程有明显的参数分支逻辑，拆分成分段的小存储过程，让不同参数走不同的执行计划。

5. 调整覆盖索引的结构 #

• 索引的键列顺序很关键：把WHERE过滤用的列放在最前面，然后是JOIN列，最后把SELECT需要的其他列用INCLUDE子句加进去，不要都塞到键列里。比如针对Feedback的索引，应该是CREATE NONCLUSTERED INDEX IX_Feedback_Status_UserId ON Feedback(Status, UserId) INCLUDE (FeedbackText, CreateDate, ...)，而不是反过来。
• 把大字段（比如VARCHAR(MAX)、NVARCHAR(MAX)）放到INCLUDE里，不要作为键列，不然索引体积会爆炸，效率急剧下降。

6. 针对超大数据量的特殊处理 #

• 如果Feedback或ApplicationUser是千万级以上的大表，哪怕是扫描一小部分也会很慢：
  • 考虑按常用过滤列（比如CreateDate）做分区表，这样查询只会扫描目标分区，直接减少扫描的数据量。
  • 把半年/一年以上的历史数据归档到单独的归档表，让当前业务表的数据量维持在合理范围。

内容的提问来源于stack exchange，提问作者Ramanathan Iyer