最简解法是用同类型局部变量赋值后替代原始参数，彻底断开参数嗅探链；需声明declare @local_date date = @input_date，后续仅用@local_date，且变量名须避让字段名以防解析失效。

直接用局部变量“断开”原始参数，是 SQL Server 2019 下最稳、改动最小、风险最低的解法。

用 @local_var 替代 @param 彻底绕过嗅探

参数嗅探只发生在编译时对入参值的“嗅探”，而本地变量在编译期无值，优化器无法基于它生成特定计划——这就天然切断了嗅探链。

• 在存储过程开头立即声明同类型变量并赋值：DECLARE @local_date DATE = @input_date;
• 后续所有 WHERE、JOIN、ORDER BY 中只用 @local_date，绝不再出现 @input_date
• 变量名必须避开表字段名（比如别叫 @id 而表里有 id 字段），否则可能被解析成 T.id = T.id，导致过滤失效
• 该方法不影响 OPTION (RECOMPILE) 等查询提示，可叠加使用

OPTION (RECOMPILE) 和 OPTIMIZE FOR UNKNOWN 怎么选

两者都作用于单条语句，不是整个存储过程；选错反而放大问题。

• OPTION (RECOMPILE)：每次执行都重编译，适合低频但参数差异极大（如查“近7天” vs “三年前”）、或数据倾斜严重（某值占 95%，另一值仅 0.1%）的语句
• OPTION (OPTIMIZE FOR UNKNOWN)：让优化器忽略具体值，按列统计信息估算选择率，适合高频调用、参数分布较均匀的 OLTP 查询（如每秒多次的订单状态查询）
• 别用 WITH RECOMPILE 在存储过程头——它强制整个过程重编译，含多个语句时浪费 CPU，且无法复用中间结果缓存

为什么 SSMS 里快、应用里慢？先查 SET 选项

同一段逻辑结果不一致或性能跳变，大概率不是参数嗅探，而是会话级配置不一致。

• ARITHABORT 必须统一：客户端默认 ON，SSMS 新建查询默认 OFF，会导致执行计划被当成两个不同计划缓存
• SET NOCOUNT ON 必须放在 BEGIN 后第一行；漏写会导致 DML 返回“(X 行受影响)”消息，某些驱动（如旧版 pyodbc）会把它当额外结果集截断主查询
• 别写成 SET NOCOUNT = ON——语法错误，过程根本创建不了
• 其他需核对项：ANSI_NULLS、QUOTED_IDENTIFIER、事务隔离级别

真正难处理的从来不是“怎么加提示”，而是确认当前慢是不是真由参数嗅探引起——执行计划缓存时间、首次调用参数值、字段与变量名是否冲突、SET 选项是否一致，这些细节一漏，就容易在错误方向上花半天。