参数嗅探本质是执行计划复用错位，SQL Server将首次参数值当作“真相”生成并缓存计划，后续参数分布差异大时导致性能骤降或结果异常；最简解法是用同类型局部变量赋值后替代原始参数，彻底断开嗅探，同时避免变量名与字段名冲突，并统一SET选项与会话配置。
参数嗅探导致执行慢或结果异常，本质是执行计划复用错位
不是 SQL 写错了，也不是索引失效了，而是 SQL Server 2019 默认把第一次传入的 @param 值当“真相”来生成执行计划，缓存后反复套用。比如首次查的是高频值（如 '20230101'），优化器选了索引查找；后续查低频值（如 '20251231'）却硬套同一计划，被迫走书签查找甚至全表扫描——耗时从 2 秒飙到 8 分钟，或者因统计偏差漏行/多行。
用局部变量“断开”参数嗅探最简单有效
这是 SQL Server 2019 兼容性下改动最小、风险最低的解法，适用于绝大多数 OLTP 场景。
- 在存储过程开头声明同类型局部变量，立即赋值：
DECLARE @local_date DATE = @input_date; - 所有 WHERE / JOIN 条件中只使用
@local_date，彻底不引用原始参数@input_date - 避免变量名与字段名冲突（例如别叫
@id而表里有id字段），否则可能被解析成T.id = T.id导致过滤失效 - 注意：该方法对查询提示（如
OPTION (RECOMPILE)）无影响，可叠加使用
按场景选查询提示：OPTIMIZE FOR UNKNOWN vs RECOMPILE
SQL Server 2019 支持更精细的控制，但选错会放大问题。
-
OPTION (OPTIMIZE FOR UNKNOWN)：让优化器忽略参数具体值，基于列统计信息估算选择率。适合参数分布较均匀、且执行频率高的过程（如每秒调用多次的订单查询） -
OPTION (RECOMPILE)：每次执行都重新编译，生成完全匹配当前参数的计划。适合低频但参数差异极大、或数据倾斜严重的场景（如日终报表按日期跑，'20230101'和'20251231'行数差 1000 倍） - 不要在存储过程头加
WITH RECOMPILE：它强制整个过程重编译，含多个语句时浪费严重；优先用语句级OPTION (RECOMPILE) - 慎用
OPTIMIZE FOR (@p = 'xxx')：仅当某类参数值占绝对主导（如 95% 是近 7 天数据），且你确认该值能代表多数情况
别忽略 SET 选项和会话配置差异
同一段逻辑在 SSMS 里快、在应用里慢，大概率不是参数嗅探，而是环境不一致。
- 检查是否漏了
SET NOCOUNT ON：默认OFF时，每条 DML 返回 “(X 行受影响)” 消息，某些驱动（如旧版 pyodbc）会把它当结果集截断主查询 -
ARITHABORT必须统一：客户端连接默认为ON，而 SSMS 新建查询默认为OFF，会导致执行计划被当成两个不同计划缓存，间接加剧参数嗅探表现 - 事务隔离级别不同（如应用用了
SNAPSHOT，SSMS 是READ COMMITTED）会影响锁行为和执行路径，尤其在高并发更新场景 - 验证方式：在 SSMS 中执行
DBCC USEROPTIONS，对比应用连接池实际生效的 SET 项
真正难处理的从来不是单个慢查询，而是那些在测试环境永远不暴露、上线后隔三差五卡住的“幽灵性能抖动”——它们往往藏在参数嗅探 + 局部变量命名冲突 + ARITHABORT 隐式切换的组合里，缺一不可地凑齐才触发。
