参数嗅探是sql server默认行为，本质是首次编译值与后续运行值严重错位导致执行计划劣化；可通过查询计划中parametercompiledvalue与parameterruntimevalue比对确认，推荐用declare @local = @param绕过。
参数嗅探不是 bug，是 SQL Server 2019 的默认行为；变慢的核心原因是首次执行时用某个参数值生成的计划，被后续差异巨大的参数复用——比如第一次查 10 行，第二次查 50 万行，却都走索引查找，IO 爆炸。
怎么确认真是参数嗅探在作怪
别靠“感觉”，直接查缓存里的编译值和运行值是否严重错位：
- 用
sys.dm_exec_query_stats找到该存储过程的plan_handle - 用
sys.dm_exec_text_query_plan(plan_handle, ...)提取 XML 执行计划，搜索<parameterlist></parameterlist>标签 - 比对
ParameterCompiledValue（编译时用的值）和ParameterRuntimeValue（当前实际传入值）——如果一个是'Active'（95% 数据），另一个是'Archived'（0.1% 数据），基本坐实 - 再看执行计划里是不是两次都用了
Clustered Index Scan或Index Seek，而实际选择性已翻转
DECLARE @local = @param 是最稳的绕过方式
它不重编译、不加提示、不改统计信息，只靠“让优化器看不见真实值”来生成通用计划，等效于 OPTIMIZE FOR UNKNOWN，但更轻量、兼容性更好。
- 必须一步赋值：
DECLARE @LocalStatus NVARCHAR(10) = @status，别用SET @LocalStatus = @status（旧版本可能穿透） - 变量类型和长度要完全一致：如果
@status是VARCHAR(50)，就别声明成VARCHAR(20)或CHAR(50)，否则隐式转换会破坏索引使用 - 每个参数都要单独声明：不能写
DECLARE @p1 INT = @p1, @p2 DATE = @p2，SQL Server 不支持这种批量初始化语法 - 别用和字段名同名的变量：比如表里有
id字段，就别叫@id，否则WHERE id = @id可能被解析成恒真式
OPTION (RECOMPILE) 只加在具体慢语句末尾
它精准但贵——每次执行都重走一遍编译流程，适合低频、参数跨度极大、且单次耗时远高于编译开销的场景（比如后台报表、分页 OFFSET 从 10 到 1000000）。
- 加在子查询或 SELECT 语句末尾，例如：
SELECT * FROM orders WHERE status = @status OPTION (RECOMPILE) - 绝对不要加在存储过程定义头上：
CREATE PROCEDURE ... WITH RECOMPILE会让整个过程每次调用都重编译，CPU 压力陡增 - 也不要在 EXEC 调用时加：
EXEC sp_xxx WITH RECOMPILE只影响本次，不解决缓存污染问题 - 注意副作用：加了
OPTION (RECOMPILE)的语句无法利用统计信息自动触发重编译，哪怕数据分布已变
容易被忽略的环境与结构陷阱
很多“变慢”根本不是参数嗅探，而是环境或嵌套结构放大了问题：
-
ARITHABORT设置不一致：SSMS 默认OFF，多数应用连接默认ON，会导致同一段逻辑被当成两个不同计划缓存，看起来“SSMS 里快，程序里慢” - 嵌套子查询没走索引：比如
WHERE id IN (SELECT id FROM t WHERE flag = @flag)，若t.flag没索引，子查询会被外层驱动 N 次，参数再准也救不了 - 局部变量只在 WHERE/JOIN 条件里有效：不能用于
IF @x > 0判断分支，也不能用于INDEX HINT或分区裁剪表达式，否则失效 - 别忘了更新统计信息：
UPDATE STATISTICS或sp_updatestats，尤其当数据量突增或分布明显偏移后
