为何非目标常量能规避SQL Server参数嗅探？及相关疑问

表结构与索引定义 #

create table Credit (ID_Credit int identity, ID_PayRequestStatus int, ... 20 more fields)
create nonclustered index Credit_ix_PayRequestStatus ON dbo.Credit(ID_PayRequestStatus)

数据分布情况 #

该表共约20万行数据，ID_PayRequestStatus字段的行分布如下：

测试查询与执行计划 #

查询1：未做参数嗅探规避 #

declare @ID_Status int = 200
select * from Credit where ID_PayRequestStatus = @ID_Status

执行计划：采用主键聚集索引扫描，SSMS建议创建包含全表字段的同列索引，属于典型的参数嗅探问题。

查询2：使用OPTIMIZE FOR规避 #

declare @ID_Status int = 200
select * from Credit 
where ID_PayRequestStatus = @ID_Status
OPTION (OPTIMIZE FOR (@ID_Status=100))

执行计划：采用Credit_ix_PayRequestStatus索引的查找操作。

核心问题：为何使用非目标优化的常量值能规避参数嗅探？ #

参数嗅探的本质是SQL Server编译参数化查询时，会用首次执行的参数值生成执行计划并缓存复用。当后续参数对应的数据分布与首次参数差异极大时，就会出现计划不匹配的问题。

使用OPTION (OPTIMIZE FOR (@ID_Status=100))时，SQL Server会强制以指定的常量值（100）作为基数估计的依据生成执行计划，完全忽略实际传入的参数值（200），编译阶段也不会“嗅探”实际参数的分布情况。由于值100对应的行数仅450行，属于极低占比数据，SQL Server会选择效率更高的非聚集索引查找（先通过索引定位行键，再回表获取全字段数据），而非扫描整个聚集索引。

这种方式直接绕过了参数嗅探的触发逻辑——不再依赖实际传入的参数值生成计划，而是固定用指定值做基数估计，自然规避了参数嗅探导致的计划劣化问题。

次要问题：SQL Server为何初始采用索引扫描？低占比查询为何未触发自动统计信息优化？ #

1. 初始采用索引扫描的原因 #

SQL Server首次编译该参数化查询时，会“嗅探”当时传入的参数值。如果首次传入的是高占比的400（占99%行），生成的执行计划会选择聚集索引扫描（因为扫描比索引查找+回表的成本更低），并将该计划缓存。后续即使传入低占比的200，SQL Server也会复用缓存的扫描计划，这就是参数嗅探导致的典型问题。

另外，即使首次传入的是200，如果统计信息的直方图无法精准反映低占比值的分布（比如该值不在直方图的关键步骤中），基数估计器可能会高估行数，进而判断扫描聚集索引的成本更低，最终选择扫描计划。

2. 未触发自动统计信息优化的原因 #

自动统计信息更新的触发条件是数据变更量达到阈值（大表通常是500行+20%的数据变更），但这里的问题并非统计信息过时，而是参数嗅探导致的计划复用问题。即使统计信息完全准确，只要缓存的执行计划是基于高占比参数生成的，SQL Server就不会自动重新编译计划，除非遇到计划强制重编译的触发条件（如统计信息更新、表结构变更、缓存过期等）。

此外，SQL Server的基数估计器在处理极度倾斜的数据分布时，对低占比参数的行数估计可能存在偏差，导致错误选择扫描计划，但这不属于统计信息未优化的范畴，而是基数估计逻辑本身的局限性。

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