参数嗅探是SQL Server首次根据传入参数生成执行计划并缓存，导致后续不同参数下复用低效计划；确认方法包括查sys.dm_exec_cached_plans中usecounts是否为1、对比sys.dm_exec_query_stats中avg_logical_reads和avg_elapsed_time随参数变化情况，以及用SET STATISTICS XML ON观察执行计划是否一致；优化方案优先选用OPTIMIZE FOR UNKNOWN或OPTIMIZE FOR典型值，辅以局部变量法，避免动态SQL、类型不匹配及SET选项不一致导致缓存失效。
不是“首次快后续慢”，而是首次执行生成了不适用于后续参数的执行计划，缓存后反复复用——问题核心在参数嗅探（Parameter Sniffing），不是执行本身变慢。
怎么确认是参数嗅探导致的性能滑坡
别只看执行时间，查底层缓存状态和实际计划：
- 运行
SELECT plan_handle, usecounts, objtype FROM sys.dm_exec_cached_plans WHERE objtype = 'Proc'，找到对应存储过程；如果usecounts恒为 1，说明根本没缓存成功，每次都在重编译（可能是EXEC(@sql)、WITH RECOMPILE或 SET 选项不一致） - 查该
plan_handle在sys.dm_exec_query_stats中的avg_logical_reads和avg_elapsed_time：突然飙升且与参数值强相关（比如传@cid = 100耗时 0.1s，传@cid = 500000耗时 12s），基本锁定参数嗅探 - 在 SSMS 中执行
SET STATISTICS XML ON后调用过程，看执行计划里是否出现 “Recompile” 标记，或对比两次调用的计划 XML 是否完全一样
OPTIMIZE FOR UNKNOWN 比 RECOMPILE 更轻量实用
OPTION (RECOMPILE) 看似一劳永逸，但代价是每次执行都走完整优化流程，CPU 升高、缓存失效，在 OLTP 高频场景下可能比跑错计划还糟。
-
OPTION (OPTIMIZE FOR (@pid UNKNOWN))告诉优化器忽略具体参数值，纯靠统计信息估算行数——适合参数分布不可预测、取值跨度大的场景（如客户 ID 从 1 到 800 万） -
OPTION (OPTIMIZE FOR (@pid = 5000))更精准：用典型值生成计划，运行时仍用真实值。比如订单查询中，90% 请求集中在最近 30 天，就写OPTIMIZE FOR (@dt = '2026-09-01') - 局部变量法也有效：
DECLARE @local_dt DATETIME = @input_dt，后续 WHERE 全部用@local_dt——优化器无法嗅探原始参数，只能依赖统计信息
哪些写法会让缓存形同虚设
即使加了 OPTIMIZE FOR，以下操作也会让计划缓存直接失效：
- 在存储过程中拼接动态 SQL 并用
EXEC(@sql)执行：SQL Server 无法预知语句结构，每次都是新计划 - 客户端传参类型和存储过程定义不一致，比如 .NET 传
int，而过程定义为smallint，引发隐式转换 + 计划不复用 - 同一数据库中，不同连接会话的
SET ARITHABORT开关不一致：一个开、一个关，SQL Server 视为两个不同上下文，各自编译 - 表结构变更、统计信息过期（
DBCC SHOW_STATISTICS查Modification Counter是否远超行数 20%）也会触发后台自动重编译
真正难处理的不是单个参数值，而是当多个参数组合导致计划分支爆炸——比如 IF @mode = 'A' AND @flag = 1 和 IF @mode = 'B' AND @flag = 0 共享同一个缓存计划，优化器只能折中。这种情况下，拆成独立小过程比堆 CASE 更可靠。
