CommandTimeout仅控制客户端从发送请求到接收首行结果的等待时间，不包含结果读取、网络传输等环节；实际断连由SQL Server端remote query timeout、网络设备空闲超时中的最小值决定。
单纯调高 CommandTimeout 不能解决存储过程执行超时问题，反而可能掩盖锁等待、统计信息陈旧或执行计划固化等真实瓶颈。
CommandTimeout 到底控制什么？
CommandTimeout 是 ADO.NET 客户端层面的设置，单位为秒，默认值 30。它只约束「从发送 RPC 请求到收到第一行结果」的等待时间，不包含后续结果集读取、网络传输、客户端处理等环节。
常见误解是“设成 600 就能撑住 10 分钟”，但实际断连往往更早发生：
- SQL Server 端的
remote query timeout（默认 600 秒）可能被禁用或覆盖 - 负载均衡器、防火墙常设 90 秒空闲超时，TCP 连接直接被切断，客户端收不到正常异常，而是
System.Data.SqlClient.SqlException: A transport-level error has occurred - Entity Framework 中
DbContext.Database.CommandTimeout必须在FromSqlRaw()或ExecuteSqlRaw()调用前设置；链式调用如.AsNoTracking()会重置该配置
为什么 WAITFOR DELAY 不延长超时判定？
SQL Server 的超时计时器从客户端发出请求那一刻启动，与存储过程中是否执行 WAITFOR DELAY 完全无关。写 WAITFOR DELAY '00:10:00' 只会让语句暂停 10 分钟，但总耗时一旦超过客户端 CommandTimeout，连接就会被主动中断——SQL Server 可能仍在执行，但客户端已收不到任何结果。
真正可行的“让步”方式是应用层异步化：
- 插入任务记录表 + 触发 SQL Agent Job 或 Service Broker
- 前端轮询状态（如查
SELECT Status FROM TaskLog WHERE Id = @taskId） - 避免在 Web 请求线程中死等一个长事务返回
SET LOCK_TIMEOUT 才是存储过程内唯一可控的“刹车”
这是 SQL Server 原生支持的语句级锁等待控制机制，必须显式写在存储过程开头：
SET LOCK_TIMEOUT 5000;
注意点：
- 单位是毫秒；
0表示锁冲突立即失败，-1（默认）表示无限等待 - 只对锁等待生效（如 KEY LOCK、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')查看最后更新时间戳（注意知识库中该信息时间戳为 2026年5月13日） - 检查 WHERE 条件是否隐式导致索引失效，例如
WHERE YEAR(OrderDate) = 2024应改为WHERE OrderDate >= '2024-01-01' AND OrderDate < '2025-01-01'
复杂点在于：很多“超时”根本不是时间不够，而是某一行卡在锁上不动了，而你却在客户端拼命加 CommandTimeout——它既不加速执行，也不释放资源，只让问题更难定位。
