单纯调高CommandTimeout不能解决存储过程执行超时问题，因其仅控制客户端等待首行结果时间，不涵盖结果集读取；SQL Server端remote query timeout、网络设备空闲超时及ADO.NET层行为共同作用，最小值决定实际断连时机；真正有效的是SET LOCK_TIMEOUT配合执行计划优化、破参数嗅探和逻辑拆分。
单纯调高 CommandTimeout 不能解决存储过程执行超时问题，反而可能掩盖真实瓶颈，甚至引发连接池耗尽、线程挂起等更严重后果。
为什么 CommandTimeout 常常“设了也白设”
它只控制客户端从发命令到收到第一行结果的等待上限，不包含后续结果集读取时间；而 SQL Server 端有独立的 remote query timeout（默认 600 秒），网络设备（如 LB、防火墙）还有自己的空闲超时策略（常见 90 秒）。三者中最小的那个会先触发断连——你设了 CommandTimeout = 600，但 LB 在 90 秒就切断了 TCP 连接，客户端根本等不到超时抛异常，而是直接报 System.Data.SqlClient.SqlException: A transport-level error has occurred...。
-
CommandTimeout是 ADO.NET 层行为，Entity Framework 中必须在FromSqlRaw()或ExecuteSqlRaw()调用前设置，且不能被AsNoTracking()等链式调用覆盖 - JDBC 用户要注意：
socketTimeout（TCP 层）和queryTimeout（Statement 级）是两个独立开关，混用会导致预期外中断 - SQL Server Agent Job 或 SSIS 调用存储过程时，
CommandTimeout完全不生效，得看作业步骤的“超时（秒）”配置项
SET LOCK_TIMEOUT 才是存储过程内真正可控的“刹车”
这是 SQL Server 唯一能在语句级干预锁等待时长的原生机制。它不解决慢查询本身，但能防止一条 UPDATE 卡在锁上把整个流程拖死。
- 必须在存储过程开头显式写
SET LOCK_TIMEOUT 5000，值单位为毫秒；设为0表示冲突立即失败，设为-1（默认）表示无限等待 - 只对锁等待生效（如
SELECT等 KEY LOCK、UPDATE等 PAGE LOCK），对 CPU 密集型操作（大排序、递归 CTE）或 I/O 瓶颈完全无效 - 错误号是
1222（锁超时），不是1205（死锁），CATCH 块里要按号区分处理 - 配合
TRY...CATCH+WAITFOR DELAY '00:00:00.1'可实现轻量重试，但必须用局部变量计数，最多 3 次，否则可能雪崩
真正该优先做的三件事
调超时是兜底手段，不是优化动作。以下操作见效更快、风险更低：
- 查执行计划：在 SSMS 中右键存储过程 → “显示估计的执行计划”，重点看是否有“聚集索引扫描”“表扫描”“警告图标”，再用
DBCC SHOW_STATISTICS('table_name', 'index_name')确认统计信息是否陈旧 - 破参数嗅探：在关键查询后加
OPTION (RECOMPILE)，或把输入参数赋给局部变量再参与 WHERE 条件（如DECLARE @p INT = @input_param） - 拆逻辑：把单次大查询改成“插入任务表 + 启动 SQL Agent Job + 应用轮询状态”，让长时间操作脱离 HTTP 请求生命周期
最常被忽略的一点：WAITFOR DELAY 在存储过程中不会暂停任何超时计时器——它只让当前会话休眠，客户端的 CommandTimeout 和 SQL Server 的 remote query timeout 都照常倒数。别指望靠它“撑过超时”。
