SQL Server存储过程中TRY/CATCH无法捕获1205死锁错误，因其由引擎直接终止执行上下文；必须由外部批处理（如SSMS、SQL Agent或应用层）包裹EXEC调用，配合WHILE循环、ERROR_NUMBER()=1205判断、WAITFOR DELAY延时及最多3次重试来实现可靠重试。
存储过程里 TRYCATCH 捕获不到 1205 错误
死锁发生时，SQL Server 不会等 TRYCATCH 进入 CATCH 块——它直接终止当前事务并抛出错误 1205，整个执行上下文被清空。你在存储过程内部写的 BEGIN TRY...END TRY BEGIN CATCH...END CATCH 对 1205 完全无效。
常见错误现象：
- 在
AFTER UPDATE触发器里加了TRYCATCH，仍看到应用层报Transaction (Process ID XX) was deadlocked - 存储过程中
WAITFOR DELAY放在CATCH里，但根本不会执行到那行 - 误以为
SET XACT_ABORT ON或SET LOCK_TIMEOUT能“拦截”死锁——它们对 1205 零作用
真正能捕获 1205 的位置：调用方批处理
唯一可控的捕获点，是执行该存储过程的外部 T-SQL 批处理（比如 SSMS 查询窗口、SQL Agent 作业步骤、或应用层拼接的完整语句）。你必须把 EXEC your_proc 包裹进带重试逻辑的 WHILE 循环中。
关键实操建议：
- 用
ERROR_NUMBER() = 1205做精确判断，不要捕获所有错误后统一重试 -
WAITFOR DELAY '00:00:00.05'起步，避免重试风暴；超过 3 次就应放弃，防止雪崩 -
ROLLBACK TRANSACTION在CATCH中无需显式写——SQL Server 已自动回滚，再写会报错 “The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION” - 重试前别改参数值（比如自增ID、时间戳），否则可能引发数据不一致
为什么不能在存储过程里加重试逻辑
存储过程一旦因死锁退出，其内部所有局部变量、临时表、游标状态全部丢失。你无法在同一个上下文中“续上”上次失败的操作。
典型陷阱：
- 在存储过程开头声明
@retry INT = 0，然后想在CATCH里递增并IF @retry —— <code>GOTO不会跳回已退出的上下文，语法也不允许跨TRY/CATCH边界 - 试图在
CATCH里重新BEGIN TRANSACTION并调用自己 —— 此时事务早已结束，且嵌套调用极易放大锁持有时间 - 把重试逻辑塞进触发器 —— 触发器生命周期极短，且多个触发器叠加会让锁路径更不可控
替代方案：用应用层控制重试更可靠
比起在 SQL 层硬塞重试，由应用代码（C#、Java、Python）捕获 SqlException.Number == 1205 后重发请求，更灵活也更安全。
优势包括：
- 可记录每次重试的原始参数与耗时，便于事后分析竞争热点
- 能结合业务语义做降级（比如首次失败查缓存，二次失败返回默认值）
- 避免 SQL 层无限循环拖垮连接池，尤其在高并发下
- 绕过 SQL Server 对嵌套事务和
SAVE TRANSACTION的限制
最易被忽略的一点：死锁不是 bug，而是并发设计的信号。与其反复重试，不如检查存储过程里是否用了 SELECT ... WITH (UPDLOCK, HOLDLOCK) 却没配索引，或两个过程更新 orders 和 customers 的顺序不一致——这些才是根因。
