参数嗅探是sql server为省编译开销而设计的默认行为，首次执行时依据参数值生成并缓存执行计划，后续调用直接复用，导致参数分布差异大时性能骤降。
根本原因不是SQL写错了，而是执行上下文不同：参数嗅探、变量名冲突、SET选项（如NOCOUNT）、事务隔离级别或连接配置差异，都会让同一段逻辑产出不同结果。
SQL Server 中参数嗅探（Parameter Sniffing）导致性能与结果偏差
存储过程首次编译时，优化器会“嗅探”传入的实际参数值生成执行计划；后续调用若参数选择率差异极大（如查“活跃用户” vs “停用用户”），复用旧计划可能走全表扫描或错误索引，导致超慢甚至返回空/多行——而直接执行 SQL 是即编译即优化，用的是当前参数的最优路径。
- 典型表现：
EXEC pro_ImAnalysis_daily '20230101'耗时 108 分钟，但把里面SELECT ... WHERE THEDATE = '20230101'拿到 SSMS 执行只要 12 秒 - 临时验证：加
WITH RECOMPILE强制每次重编译，或在过程内用局部变量“断开嗅探”：DECLARE @local_date VARCHAR(30) = @THEDATE; ... WHERE THEDATE = @local_date - 长期解法：SQL Server 2016+ 可启用数据库级参数敏感性开关，或对关键过程用
OPTIMIZE FOR (@THEDATE = '20230101')提示
变量名与字段名同名引发 Oracle/SQL Server 隐式解析错误
当存储过程中定义的变量名和表字段名完全一致（如变量 COLUMN_3 和表字段 T.COLUMN_3），WHERE 条件 T.COLUMN_3 = COLUMN_3 会被解析为恒真式（T.COLUMN_3 = T.COLUMN_3），实际过滤失效——而你手动粘贴的 SQL 里全是字面量值，自然正常。
- Oracle 和 SQL Server 均存在此行为，尤其在未加表别名或作用域限定时更易触发
- 检查方法：在存储过程开头加
SET NOCOUNT ON后，用 SSMS 的“包含实际执行计划”运行，看 WHERE 谓词是否消失或变成1=1 - 修复动作：统一将入参或中间变量重命名为带前缀形式，如
@p_column3、v_column3，避免与任何字段名重叠
SET NOCOUNT OFF / ANSI_WARNINGS 等会话级设置干扰结果集结构
SET NOCOUNT OFF（默认）会让每条 INSERT/UPDATE 返回“(X 行受影响)”消息，某些客户端驱动（pyodbc、旧版 JDBC）会把这些当额外结果集接收，导致你 fetchall() 拿到空，或 getResultSet() 读到第一条是乱码——而 SSMS 默认忽略这些消息，看起来完全正常。
- 必须把
SET NOCOUNT ON放在BEGIN后第一行，否则前面语句仍发消息 - 别写成
SET NOCOUNT = ON（语法错误，过程无法创建） - 其他需检查的会话设置：
ANSI_NULLS、QUOTED_IDENTIFIER、ARITHABORT—— 它们影响空值比较、标识符解析和除零行为，且在 SSMS 新查询窗口默认开启，但应用连接字符串可能未显式指定
MySQL 驱动版本与时区配置引发的时间值错位
MySQL Connector/J 8.0.22 之前版本存在 LocalDateTime 解析 bug：应用传 2023-01-01 10:00:00，驱动可能按客户端时区转成服务端时间再发送，导致 WHERE 条件实际匹配了错误小时——而你在命令行或 DBeaver 里手输字符串，绕过了驱动转换逻辑。
- 现象：按日期范围查数据，程序返回空，但把日志里打印出的 SQL 拷进 MySQL CLI 就能查到
- 验证方式：在连接字符串中强制指定时区，如
?serverTimezone=Asia/Shanghai&useTimezone=true - 根治方案：升级驱动至 8.0.22+，并改用新坐标
com.mysql:mysql-connector-j（旧mysql:mysql-connector-java已废弃）
真正容易被忽略的是：问题往往不是单点故障，而是多个环境差异叠加——比如 Oracle 存储过程里变量名冲突 + 未设 SET CURRENT_SCHEMA + 客户端连接用了不同默认 schema，三者同时存在时，连错误日志都看不出明显线索。
