SQL Server未为UPDATE查询使用筛选索引的问题求助

为什么筛选索引未被使用？ #

1. 空结果集的优化器决策逻辑 #

当表中不存在UniqueSessionId IS NULL的行时，SQL Server查询优化器会对比不同执行路径的成本：遍历筛选索引的开销，并不一定比扫描一个更小的非聚集索引（或聚集索引）更低。尤其是当筛选索引的体积没有明显优势时，优化器会倾向于选择它判定“更廉价”的执行方式——哪怕最终返回0行。

2. UPDATE语句的索引依赖限制 #

筛选索引要被UPDATE语句选用，需满足两个核心条件：

• WHERE子句完全匹配索引的过滤条件（此场景中是匹配的）
• UPDATE涉及的所有列要么是索引键列，要么是索引包含列
  你的筛选索引仅包含ServerName、SessionId、CreatedTime三个键列，但UPDATE的目标列UniqueSessionId不在索引中。若使用该索引，优化器需要额外执行**键查找（Key Lookup）**去获取表中的UniqueSessionId列（即便当前该列全为NULL，优化器无法提前知晓）。优化器判定键查找的成本高于直接扫描包含UniqueSessionId的索引，因此放弃了筛选索引。

如何让筛选索引被正确使用？ #

1. 添加目标列为索引包含列 #

修改筛选索引，将UniqueSessionId作为包含列加入，这样优化器无需额外键查找就能获取所有所需列：

CREATE NONCLUSTERED INDEX [IDX_Speedup_04] 
ON [Sessions] ([ServerName] ASC, [SessionId] ASC, [CreatedTime] ASC)
INCLUDE ([UniqueSessionId])
WHERE ([UniqueSessionId] IS NULL)

重建索引后再执行UPDATE语句，优化器应该会选择该筛选索引——因为索引已覆盖所有需要的列，消除了键查找的额外成本。

2. 强制指定索引（仅用于验证，不推荐生产环境） #

若仅需验证筛选索引是否可用，可通过WITH(INDEX(...))强制指定索引：

UPDATE [Sessions] WITH(INDEX(IDX_Speedup_04))
SET UniqueSessionId = COALESCE(ServerName, '') + '-' + SessionId + '-' + CONVERT(VARCHAR(12), CAST(CreatedTime AS DATE), 120)
WHERE UniqueSessionId IS NULL 

注意：生产环境不建议长期使用强制索引，优化器的决策通常基于当前数据分布的最优解。

为什么扫描0行仍显示键查找？ #

执行计划是基于统计信息预估生成的，而非实时判断是否存在匹配行。即便实际没有符合条件的行，执行计划仍会保留“找到匹配行后需执行键查找”的逻辑——因为统计信息是采样生成的，可能无法实时反映“所有行的UniqueSessionId均不为NULL”的全量状态。实际执行时，扫描阶段发现0行后，键查找阶段不会被触发，但执行计划中仍会显示该步骤。

内容的提问来源于stack exchange，提问作者Payal Bansal