参数嗅探是sql server用首次参数值生成并缓存执行计划的行为，可能导致后续不同参数下性能骤降；其本质是优化器在通用性与针对性间的权衡，需依实际监控数据选择应对策略。
什么是参数嗅探，为什么它会突然让存储过程变慢
参数嗅探不是 bug，是 SQL Server 的正常行为：它在第一次执行存储过程时，用传入的参数值生成并缓存一个执行计划。问题在于，这个计划可能只对“那个特定参数”高效——比如传 @CustomerId = 1 时走索引查找，但传 @CustomerId = 999999（匹配百万行）时还硬套同一个计划，结果变成索引扫描+大量逻辑读，耗时从 50ms 暴涨到 8s。
你不会在开发环境发现它，因为测试数据少；也不会在日志里看到报错，只有监控里 total_logical_reads 突然翻倍、execution_count 高但 avg_elapsed_time 波动剧烈——这是最典型的信号。
OPTION (RECOMPILE) 什么时候该用，什么时候不该用
加 OPTION (RECOMPILE) 是最直接的解法，但它不是万能膏药。每次执行都重新编译，等于放弃计划复用优势，CPU 开销会上升。
- 适合场景：参数取值差异极大（如“查单个用户” vs “查全公司员工”）、执行频次低（每小时最多几次）、且逻辑本身不复杂（编译耗时可控）
- 不适合场景：高频调用（如每秒几十次的订单查询）、含大量 JOIN 或 CTE 的重型查询（编译本身就要几毫秒）
- 实操建议：先在测试环境用
SET STATISTICS XML ON对比加/不加的效果，重点看CompileCPU和CompileTime是否显著拖累整体响应
OPTIMIZE FOR 提示怎么写才不踩坑
OPTIMIZE FOR 是折中方案：告诉优化器“按这个典型值生成计划”，后续所有调用都复用它。但它容易被误用成“猜答案”。
- 别写
OPTIMIZE FOR (@p = UNKNOWN)：这会让优化器用统计信息平均值估算，往往不如真实参数靠谱 - 正确做法：从
sys.dm_exec_query_stats+sys.dm_exec_sql_text中查出该过程最常出现的参数值（比如@Status = 'Active'占 70% 调用），再写OPTIMIZE FOR (@Status = N'Active') - 注意类型匹配：字符串必须带
N''前缀，数字别漏小数点（@Amount = 100.0而非@Amount = 100），否则提示可能失效
切换存储过程版本时，必须清缓存的两个动作
多版本对比测试时，旧计划残留是最隐蔽的误差源。哪怕你改了代码、重建了过程，SQL Server 可能还在用上次缓存的计划。
- 安全做法：每次
ALTER PROCEDURE后，立刻执行DBCC FREEPROCCACHE清掉该过程相关计划。更精准的是先查plan_handle：SELECT plan_handle FROM sys.dm_exec_cached_plans cp<br>CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st<br>WHERE st.text LIKE '%usp_GetOrderList%';
再执行DBCC FREEPROCCACHE (0x06000100...) - 懒人替代方案：临时加
WITH RECOMPILE创建过程（CREATE PROCEDURE ... WITH RECOMPILE），但上线前务必删掉——它会让每次调用都重编译 - 关键提醒：不要依赖“重启 SQL Server”来清缓存，生产环境不允许；也不要只清
sys.dm_exec_procedure_stats，那只是统计视图，不清理实际计划
参数嗅探的本质是优化器在“通用性”和“针对性”之间做权衡。没有银弹方案，只有根据调用分布、数据特征和性能敏感度选最合适的那个——而判断依据，永远是 sys.dm_exec_query_stats 里真实的 total_logical_reads 和 avg_elapsed_time，不是感觉。
