SQL Server存储过程超时且CommandTimeout不生效，根本原因是客户端设置常被服务端remote query timeout或网络策略覆盖；CommandTimeout仅控制发命令到首行返回的等待时间，不含结果读取；WAITFOR DELAY不暂停超时计时器；应优先优化查询策略而非调高超时。
SQL Server 存储过程执行超时，CommandTimeout 不生效？
根本原因通常是客户端设置被服务端或网络层覆盖。比如 ADO.NET 中设置了 CommandTimeout=300，但 SQL Server 默认的 remote query timeout 是 600 秒（10 分钟），而 Windows 网络策略或负载均衡器可能只允许 90 秒连接空闲——这时客户端等不到 300 秒就断开了。
-
CommandTimeout是客户端行为，只控制从发命令到收到首行结果的等待上限，不包含结果集读取时间 - SQL Server 层需同步检查
sp_configure 'remote query timeout'，若值为 0 表示无限等待，但生产环境不建议设 0 - 如果用的是 Entity Framework，
DbContext.Database.CommandTimeout设置必须在SaveChanges或FromSqlRaw调用前生效，且不能被后续AsNoTracking()等操作覆盖 - Java 的 JDBC 需确认是否用了
socketTimeout（底层 TCP 超时）和queryTimeout（Statement 级），二者作用不同，常被混用
存储过程里写 WAITFOR DELAY 会延长超时判定吗？
不会。SQL Server 的超时计时器从客户端发出 RPC 请求那一刻启动，与存储过程中是否休眠无关。哪怕你写 WAITFOR DELAY '00:10:00'，只要总耗时超过客户端 CommandTimeout，连接就会被主动中断，SQL Server 可能仍在执行，但客户端已收不到结果。
-
WAITFOR只影响当前会话执行流，不暂停超时倒计时 - 若想“让步”给长时间操作，应在应用层拆分逻辑：先触发异步任务（如插入任务表 + 启动 SQL Agent Job），再轮询状态，而非死等一个存储过程返回
- 调试时可用
SELECT @@SPID配合sys.dm_exec_requests查看实际运行时长，验证是不是真卡在某句上，而不是单纯等超时
查询策略比调超时更有效：哪些写法会让存储过程“假性超时”？
很多超时其实不是时间不够，而是锁、统计信息陈旧或执行计划固化导致查询卡住不动。比如一个本该走索引的 WHERE 条件，因参数嗅探选了全表扫描，又碰上大表和高并发更新，直接堵在 KEY LOCK 上。
- 避免在 WHERE 中对字段用函数：
WHERE YEAR(OrderDate) = 2024会跳过索引；改成WHERE OrderDate >= '2024-01-01' AND OrderDate - 批量更新/删除务必加
TOP (n)和ORDER BY，防止锁升级成表锁；例如DELETE TOP (1000) FROM Logs WHERE CreatedAt - 用
OPTION (RECOMPILE)缓解参数嗅探，但别滥用——每次执行都重编译有开销；更适合参数值分布极不均匀的场景 - 检查执行计划中是否有
Table Spool (Eager Spool)或大量Sort，这些往往是内存不足或缺失索引的信号
MySQL / PostgreSQL 存储过程超时处理逻辑完全不同
MySQL 没有原生存储过程级超时控制，max_execution_time 只对单条 SELECT 生效，对 CALL proc_name() 无效；PostgreSQL 的 statement_timeout 可全局或会话级设置，但它中断的是整个事务，不是某个过程调用。
- MySQL 下真正可控的是客户端：JDBC 用
connectTimeout（连接建立）、socketTimeout（网络读写）、queryTimeout（Statement 执行）三者配合 - PostgreSQL 若在函数里调用
pg_sleep()，statement_timeout依然会计时，但函数内异常不会自动 rollback 外层事务，得靠EXCEPTION块手动处理 - 跨数据库迁移存储过程时，超时相关逻辑几乎都要重写，没有银弹配置
CommandTimeout 还超时？先去看 sys.dm_exec_sessions 里那个 SPID 正在等什么。 
