参数嗅探是SQL Server默认行为，其执行计划“错配”会导致性能差异数十倍；应通过sys.dm_exec_procedure_stats查时间波动、对比执行计划、DBCC FREEPROCCACHE验证，并依场景选用OPTION(RECOMPILE)、OPTIMIZE FOR UNKNOWN或本地变量。
参数嗅探不是 bug，是 SQL Server 的默认行为；但它的副作用——执行计划“错配”——会导致同一存储过程在不同参数下性能差几十倍。解决它不靠禁用，而靠控制编译时机和参数可见性。
怎么判断是不是参数嗅探导致的慢？
别猜，直接查缓存计划的执行时间波动：
- 运行
sys.dm_exec_procedure_stats查询，重点看avg_elapsed_time和last_elapsed_time差异是否超过 5 倍（比如平均 200ms，最近一次 1200ms） - 用
sys.dm_exec_query_plan拿到慢那次的执行计划，对比快那次，看是否用了完全不同的运算符（比如一个走索引查找，另一个走聚集扫描） - 执行
DBCC FREEPROCCACHE后立刻重跑，如果变快了，基本锁定是计划缓存问题，而非数据或索引本身
OPTION (RECOMPILE) 和 OPTION (OPTIMIZE FOR UNKNOWN) 怎么选？
两者都绕过首次参数值决定计划的逻辑，但机制和代价完全不同：
-
OPTION (RECOMPILE)：每次执行都重新编译该语句，生成完全匹配当前参数的计划。适合低频调用、参数分布极不均匀（如 99% 是小结果集，1% 是大结果集）、或语句本身很轻量（编译开销远小于执行开销） -
OPTION (OPTIMIZE FOR UNKNOWN)：SQL Server 忽略实际参数值，改用统计直方图的平均密度估算行数，生成“中庸但稳定”的计划。适合高频调用、对响应时间一致性要求高、且平均计划能接受（比如 95% 场景都在 300ms 内） - 注意：
OPTIMIZE FOR (@p = value)是指定固定值优化，容易固化成“偏科”计划，慎用；OPTIMIZE FOR UNKNOWN才是通用解法
为什么用本地变量能“骗过”参数嗅探？
这不是 hack，而是利用 SQL Server 编译期可见性规则：
- 存储过程参数（如
@id）在编译时是“已知值”，优化器会嗅探并绑定计划 - 但本地变量（如
DECLARE @local_id INT = @id）在编译时是“未知值”，优化器无法基于它生成特定计划，只能退回到统计信息估算 - 所以把
WHERE col = @id改成WHERE col = @local_id，效果等同于OPTIMIZE FOR UNKNOWN，且无需修改查询提示 - 缺点：丢失了参数值带来的精确基数估算，可能让本可走索引查找的场景降级为扫描——得看数据倾斜程度
WITH RECOMPILE 是不是万能钥匙？
不是，它是“粗粒度开关”，容易误伤：
-
WITH RECOMPILE作用于整个存储过程，每次调用都全量重编译，包括里面所有语句（哪怕只有 1 条 SQL 受参数影响） - 对于含多层逻辑、多表联结、大量 T-SQL 控制流的存储过程，编译开销可能比执行还高
- 真正需要的往往是语句级重编译，而不是过程级——优先用
OPTION (RECOMPILE)加在具体慢查询后，而非给整个 proc 加WITH RECOMPILE - 如果必须用
WITH RECOMPILE，务必确认调用频率足够低（比如每天几次），否则 CPU 会被编译吃掉
参数嗅探的根子不在语法，而在“计划复用”与“参数多样性”的矛盾。最稳妥的做法，是先用缓存视图确认问题存在，再根据调用频次、数据分布、语句复杂度，选择本地变量、OPTIMIZE FOR UNKNOWN 或语句级 RECOMPILE——而不是统一加个 hint 就完事。尤其要注意，覆盖索引能消除书签查找，有时比改 hint 更治本。
