子查询本身不触发参数嗅探，问题在于外部参数被优化器嗅探后生成了不适用的执行计划，尤其在where、exists或in中嵌套时偏差会被逐层放大。
子查询本身不触发参数嗅探，问题出在外部参数被优化器“嗅探”后生成了不适用的执行计划——尤其当子查询嵌套在 WHERE、EXISTS 或 IN 中时，偏差会被逐层放大。
为什么子查询会放大参数嗅探影响
子查询依赖外部参数（比如 WHERE id IN (SELECT ... WHERE status = @p_status)），SQL Server 编译整条语句时仍会基于 @p_status 的首次值估算行数。若该列数据倾斜严重（如 95% 是 'A'，5% 是 'B'），首次用 'A' 编译可能走索引查找；后续传 'B' 却复用同一计划，而 'B' 实际应走全表扫描更优，结果卡住几十秒甚至超时。
-
EXISTS/IN比JOIN更容易因参数值变化导致计划跳变，尤其未建覆盖索引时 - 嵌套越深，优化器越难准确估算基数，偏差被逐层放大
- SQL Server 2016+ 默认不启用
PARAMETER_SENSITIVE_PLAN，含子查询的语句仍按传统方式嗅探
用局部变量断开子查询中的参数传递
这是最轻量、兼容性最好的解法：把入参赋给新声明的局部变量，再在子查询中使用它。优化器编译时无法“嗅探”局部变量的值，转而生成通用计划（效果等同 OPTIMIZE FOR UNKNOWN）。
- 必须用
=赋值，不能写成SET @local_status = @status（部分旧版本中SET仍可能被推导） - 变量类型要与参数严格一致（如
@status VARCHAR(10)就别声明成@local_status CHAR(10)，隐式转换会破坏计划重用） - 对多参数子查询，每个参数都需单独声明局部变量，不能共用一个
- 避免变量名与字段名冲突（例如别叫
@id而表里有id字段），否则可能被解析为恒真式
对子查询语句加 OPTION (RECOMPILE)
当子查询逻辑固定、但参数值分布极不均匀（如查“活跃用户” vs “已注销用户”），且执行频率不高（每天几次的报表、后台任务），可直接在子查询末尾加提示。
- 只加在具体慢的子查询语句后，不是整个存储过程头——否则浪费严重
- 适用场景：参数差异极大（如分页
OFFSET从 10 到 1000000）、关键路径不能容忍计划失配 - 错误做法：
CREATE PROCEDURE ... WITH RECOMPILE（整过程重编译，CPU 压力陡增） - 注意：子查询里加了
OPTION (RECOMPILE)，主查询仍可复用计划，开销可控
别忽略会话级 SET 选项和字段名冲突
同一段逻辑在 SSMS 里快、在应用里慢，大概率不是参数嗅探，而是环境不一致或隐式解析错误。
-
ARITHABORT必须统一：客户端默认ON，SSMS 新建查询默认OFF，会导致执行计划被当成两个不同计划缓存 -
SET NOCOUNT ON漏写时，某些驱动（如旧版pyodbc）会把 “(X 行受影响)” 当结果集截断主查询 - 变量名与字段名同名（如变量
@status和表字段Status）会导致WHERE Status = @status被解析为Status = Status，过滤失效
真正麻烦的不是怎么选方案，而是判断哪一层出了问题：是子查询里的参数被嗅探了，还是外层 JOIN 条件干扰了基数估算，又或者只是字段名冲突让整个谓词失效。先查 sys.dm_exec_procedure_stats 看时间波动，再看实际执行计划里子查询部分的运算符是否异常跳变——比盲目加 RECOMPILE 有用得多。
