根本原因是执行上下文差异：参数嗅探导致计划复用失当、SET选项（如ARITHABORT、NOCOUNT）不一致引发缓存分裂与结果集错乱、变量名与字段名同名造成隐式恒真过滤，而SSMS与客户端环境配置不同使同一逻辑走不同执行路径。
根本原因不是SQL写错了，也不是服务器卡了，而是客户端连接和SSMS的默认会话设置、执行上下文、参数处理方式存在关键差异——同一段逻辑在不同环境下走的是完全不同的执行路径。
参数嗅探（Parameter Sniffing）导致计划复用失当
SQL Server 存储过程首次执行时，优化器会“嗅探”传入的@date值生成并缓存执行计划；后续调用直接复用该计划。如果客户端传入的是低选择率参数（比如查“停用用户”），却复用了为高选择率参数（如“活跃用户”）生成的索引查找计划，就可能退化成全表扫描，耗时飙升。而你在 SSMS 里粘贴SELECT ... WHERE THEDATE = '20230101'是即编译即优化，用的是当前字面量的最优路径。
- 临时验证：在存储过程定义末尾加
WITH RECOMPILE，或改写关键WHERE条件为WHERE THEDATE = @local_date（先DECLARE @local_date VARCHAR(30) = @THEDATE）来切断嗅探 - 长期解法：SQL Server 2016+ 可对数据库启用
PARAMETER_SENSITIVE_PLAN，或在过程内加OPTION (OPTIMIZE FOR (@THEDATE = '20230101')) - 注意：SSMS 默认以
SET ARITHABORT ON连接，而多数 ORM（如 Entity Framework）默认OFF——这会导致计划缓存分裂，两个连接实际用了两套执行计划
客户端未设 SET NOCOUNT ON 导致结果集错乱
存储过程中若没在BEGIN后第一行写SET NOCOUNT ON，每条INSERT/UPDATE都会返回“(X 行受影响)”消息。pyodbc、旧版 JDBC 等驱动会把这些当作额外结果集接收，导致fetchall()取不到主结果，或超时等待下一个结果集——而 SSMS 默认忽略这些消息，看起来一切正常。
- 必须把
SET NOCOUNT ON放在BEGIN之后、任何 DML 之前；写成SET NOCOUNT = ON是语法错误 - 检查客户端连接字符串是否含
Packet Size或Connection Timeout过小，尤其当过程内有大量中间结果集时
变量名与字段名同名引发隐式解析失效
当存储过程里定义了@status，又在WHERE中写t.status = @status，而表t本身也有status字段且未加表别名，SQL Server 可能将其解析为t.status = t.status（恒真），过滤彻底失效。你在 SSMS 手动执行时用的是字面量'active'，自然不受影响。
- 检查方法：在 SSMS 中开启“包含实际执行计划”，看 WHERE 谓词是否消失或变成
1=1 - 修复动作：统一给参数加前缀，如
@p_status；所有字段引用都带表别名，如t.status = @p_status - 特别注意：Oracle 和 SQL Server 均存在此行为，且在未启用
ANSI_WARNINGS或QUOTED_IDENTIFIER时更易触发
最常被忽略的一点是：你看到的“超时”，往往不是查询真卡住了，而是客户端在等一个它永远收不到的结果集，或者正在反复重试一个因会话设置不一致而持续失败的调用。排查时优先抓取客户端真实发送的 TDS 包（用 SQL Server Profiler 或 Extended Events 捕获RPC:Completed事件），而不是只盯着 SSMS 里的执行时间。
