用局部变量“断开”参数嗅探是最小改动、最低风险的通用解法，即声明同类型局部变量并赋值，后续条件中仅使用该局部变量，避开字段名冲突，可与查询提示叠加使用。
用局部变量“断开”参数嗅探最有效
这不是权宜之计，而是 SQL Server 2019 兼容性下改动最小、风险最低的通用解法。核心逻辑是让优化器无法“看到”原始参数值，从而放弃基于该值生成计划。
- 在存储过程开头声明同类型局部变量，立即赋值：
DECLARE @local_date DATE = @input_date; - 所有
WHERE、JOIN、ON条件中只使用@local_date，彻底不引用@input_date - 变量名必须避开表字段名（例如别叫
@id而表里有id字段），否则可能被解析成T.id = T.id，导致过滤失效 - 该方法对查询提示无影响，可与
OPTION (RECOMPILE)或OPTIMIZE FOR UNKNOWN叠加使用
按场景选 OPTION 查询提示
OPTION 提示不是万能开关，选错反而放大问题。关键看调用频率、参数分布和数据倾斜程度。
-
OPTION (OPTIMIZE FOR UNKNOWN)：优化器忽略参数具体值，仅依赖列统计信息估算选择率。适合参数分布较均匀、且每秒调用多次的 OLTP 场景（如订单查询） -
OPTION (RECOMPILE)：每次执行都重新编译，生成完全匹配当前参数的计划。适合低频但参数差异极大、或数据严重倾斜的场景（如日终报表按日期跑，'20230101'和'20251231'行数差 1000 倍） - 避免在存储过程头加
WITH RECOMPILE：它强制整个过程重编译，含多个语句时浪费严重；应优先用语句级OPTION (RECOMPILE) - 慎用
OPTIMIZE FOR (@p = 'xxx')：仅当某类参数值占绝对主导（如 95% 是近 7 天数据），且你确认该值能代表多数情况
别忽略 SET 选项和会话配置差异
同一段逻辑在 SSMS 里快、在应用里慢，大概率不是参数嗅探，而是环境不一致。尤其注意三个关键点：
-
SET NOCOUNT ON必须显式开启：默认OFF时，每条 DML 返回 “(X 行受影响)” 消息，某些驱动（如旧版pyodbc）会把它当结果集截断主查询 -
ARITHABORT必须统一：客户端连接默认为ON，而 SSMS 新建查询默认为OFF，会导致执行计划被当成两个不同计划缓存，间接加剧参数嗅探表现 - 其他需检查的会话设置：
ANSI_NULLS、QUOTED_IDENTIFIER——它们影响空值比较、标识符解析和除零行为，且必须与创建存储过程时一致
验证是否真由参数嗅探引起
别一上来就改代码。先确认问题根源，避免把环境配置、索引缺失或统计信息过期误判为参数嗅探。
- 临时验证：在存储过程内加
OPTION (RECOMPILE)或用局部变量替换后执行，对比耗时变化 - 查缓存计划：运行
sys.dm_exec_procedure_stats查看avg_elapsed_time与last_elapsed_time差异是否巨大（比如平均 2 秒，最近一次 300 秒） - 对比执行计划：在 SSMS 中启用“包含实际执行计划”，分别运行
EXEC proc @p='高频值'和EXEC proc @p='低频值'，看是否复用同一计划但走不同路径（如 Index Seek vs Table Scan） - 直接执行 SQL 对比：把存储过程中对应 SELECT 拷出来，替换成字面量值执行，若明显更快，基本锁定是参数嗅探或环境差异
DECLARE，而是你得同时盯住执行计划、会话设置、统计信息和参数分布这四层——漏掉任何一层，修复都只是暂时压住症状。 
