单纯调高commandtimeout基本没用，因其仅控制客户端从发命令到首行返回的等待时间，不涵盖锁等待、结果读取及网络空闲超时；实际断连由sql server端remote query timeout、网络设备空闲超时中的最小值决定；真正可控的是存储过程开头的set lock_timeout机制。
单纯调高 CommandTimeout 基本没用，它只管“发命令到第一行返回”那段时间，后面卡在锁上、读几百MB结果、等网络空闲超时，它完全不管。
为什么 CommandTimeout 经常设了也白设
这是 ADO.NET 或 JDBC 客户端的计时器，从 RPC 请求发出那一刻就倒计时。一旦 SQL Server 开始执行（哪怕刚进存储过程第一行），这个计时器就已启动。但真正断连的往往不是它：
- SQL Server 自己的
remote query timeout（默认 600 秒），查法：sp_configure 'remote query timeout' - 负载均衡器或防火墙的空闲超时（常见 90 秒），TCP 连接直接被掐断，客户端报
A transport-level error has occurred - Entity Framework 中
DbContext.Database.CommandTimeout必须在FromSqlRaw()调用前设置；.AsNoTracking()之后再设就失效 - JDBC 用户注意：
socketTimeout（TCP 层）和queryTimeout（Statement 级）是两套机制，混用会互相干扰
SET LOCK_TIMEOUT 是存储过程里唯一可控的“刹车”
这是 SQL Server 唯一能在语句级干预锁等待的原生机制，不是优化，而是防雪崩：
- 必须写在存储过程开头，例如：
SET LOCK_TIMEOUT 5000（单位毫秒） - 设为
0表示锁冲突立即失败；设为-1（默认）就是无限等 - 只对锁等待生效（如
SELECT等KEY LOCK、UPDATE等PAGE LOCK），对大排序、递归 CTE、I/O 瓶颈完全无效 - 出错抛
error 1222（锁超时），不是1205（死锁），TRYCATCH里得按号区分处理 - 配合
WAITFOR DELAY '00:00:00.1'+ 局部变量可做轻量重试，但最多 3 次，否则可能把并发拖垮
真该优先查的不是超时，而是执行计划
很多“超时”根本不是时间不够，而是执行计划选错了，比如参数嗅探导致全表扫描卡在锁上：
- 在 SSMS 中右键存储过程 → “显示估计的执行计划”，重点看有没有聚集索引扫描、表扫描或黄色警告图标
- 用
DBCC SHOW_STATISTICS('table_name', 'index_name')看统计信息是否陈旧（rows sampled远小于rows就要更新） - 临时加
OPTION (RECOMPILE)可破参数嗅探，但别滥用，编译开销本身也耗时 - 大结果集别硬扛：拆成多次小查询，或先写入临时表再关联，避免单次 RPC 长期占用连接
SQL Server Agent Job 或 SSIS 调用时，CommandTimeout 完全不生效
这类场景下客户端超时设置无效，得去对应位置改配置：
- SQL Server Agent Job：作业步骤里改“超时(秒)”配置项
- SSIS：在 Execute SQL Task 的
ExecutionTimeOut属性里设（单位秒） - Azure Logic Apps 的 SQL 连接器：存储过程操作硬性限制不到 2 分钟，超时直接报
504，必须拆逻辑或改用 Service Bus/队列异步化
最容易被忽略的是：超时设置只是兜底，不是诊断手段。真正卡住的地方，往往藏在锁等待、陈旧统计信息或固化执行计划里，而不是时间数字本身。
