parameter sniffing 是 sql server 基于首次参数值生成并复用执行计划的默认优化行为，当后续参数导致数据选择性差异大时，复用低效计划引发“突然变慢”。
SQL Server 里 parameter sniffing 是什么，为什么它会让执行计划“突然变慢”
它不是 bug，是 SQL Server 的默认优化行为：首次编译存储过程或参数化查询时，会“嗅探”当时传入的实际参数值，据此生成并缓存一个执行计划。这个计划后续会被复用——哪怕下一次传入的参数值导致数据分布差异极大（比如查用户 ID=1 和 ID=999999），也照用不误。
常见错误现象：EXEC sp_executesql N'SELECT * FROM Orders WHERE CustomerID = @cid', N'@cid int', @cid = 1 很快，但换成 @cid = 999999 就卡住；DBCC FREEPROCCACHE 后第一次又快了，过一阵又慢。
- 典型场景：报表查询、后台任务中参数跨度大（如分页 offset 极大、状态码稀疏/密集混用）
- 根本原因：SQL Server 基于单次参数生成的计划，无法适配所有可能的数据选择性
- 注意：仅影响参数化查询和存储过程，直接拼接字符串的
EXEC('SELECT...')不走缓存，但有注入风险
怎么快速判断是不是 parameter sniffing 导致的性能问题
别猜，用系统视图直接看缓存里的实际参数和对应计划。重点查 sys.dm_exec_query_stats + sys.dm_exec_sql_text + sys.dm_exec_cached_plans。
实操建议：
- 运行
SELECT qs.plan_handle, qs.execution_count, qs.last_execution_time, st.text FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st WHERE st.text LIKE '%Orders%CustomerID%'，确认是否同一语句多次执行但耗时波动大 - 对可疑
plan_handle执行SELECT * FROM sys.dm_exec_plan_attributes(@plan_handle)，检查set_options和parameter_sniffing属性是否为 1 - 用
SET STATISTICS XML ON对比两次不同参数的执行，看<queryplan></queryplan>中的ParameterCompiledValue和ParameterRuntimeValue是否严重偏离
强制参数化（OPTIMIZE FOR 和 RECOMPILE）怎么选
二者目标一致：绕过默认的参数嗅探逻辑，但策略完全不同，适用边界很清晰。
-
OPTIMIZE FOR (@param = 500)：告诉优化器“按这个典型值生成计划”，适合参数分布稳定、有明确代表值的场景（比如查Status = 1占 80% 请求）；缺点是硬编码值，上线后若业务变化，计划可能再次失效 -
OPTION (RECOMPILE)：每次执行都重新编译，彻底规避缓存问题；适合低频、参数差异极大、且编译开销远小于执行开销的查询（比如后台导出）；但高并发下会抬高 CPU，慎用于 OLTP 核心接口 - 绝对不要混用：
OPTIMIZE FOR UNKNOWN等价于关掉参数嗅探，但会退化为统计信息平均值估算，对倾斜数据更不友好
生产环境该不该开启数据库级强制参数化（PARAMETERIZATION FORCED）
不推荐，除非你完全掌控所有 SQL 写法且已做过全量压测。
原因很实在：
- 它对整个数据库生效，连
INSERT INTO #tmp SELECT ...这类临时表操作也会被强制参数化，可能引发不可预知的编译失败或计划退化 - 对存在大量字面量（literal）的动态 SQL 影响剧烈，比如
WHERE CreateTime > '2023-01-01'会被转成参数，导致本可走索引的查询变成扫描 - 兼容性风险：某些 ORM（如旧版 Entity Framework）生成的语句结构在强制参数化下可能触发重复编译或缓存污染
- 替代方案更可控：用查询提示（
OPTION (OPTIMIZE FOR)）、重写为存储过程、或在应用层做参数归一化（如把超大分页转为键集分页）
最常被忽略的一点：parameter sniffing 本身不是问题，是信号——它在提醒你，这条查询的参数分布和数据分布不匹配。盯着缓存策略调，不如先看统计信息是否更新、索引是否覆盖、谓词是否可SARG化。
