怎样在SQL存储过程中捕获并处理死锁异常-SQL-PHP中文网

sql server存储过程中try/catch无法捕获1205死锁错误，因其由引擎直接终止执行上下文；必须由外部批处理包裹exec调用，配合while循环、error_number()=1205判断、waitfor delay延时及最多3次重试来实现可靠重试。

怎样在sql存储过程中捕获并处理死锁异常

TRY...CATCH 在存储过程内部对死锁（错误 1205）完全无效——SQL Server 引擎检测到死锁后会立即终止整个执行上下文，不进入 CATCH 块。

为什么存储过程里的 `TRY...CATCH` 捕获不到 1205

死锁不是“运行时错误”，而是引擎级强制中断：事务被选为牺牲品后，所有局部变量、游标、临时表状态全部丢失，BEGIN TRY 所在的执行栈直接销毁。
ERROR_NUMBER()、ERROR_MESSAGE() 等函数在存储过程内部根本没机会被调用。
常见误操作：
- 在存储过程开头写 SET XACT_ABORT ON，以为能“兜住”死锁 → 实际无影响
- 在 CATCH 里写 WAITFOR DELAY '00:00:00.1' 再重试 → 这行代码永远不会执行
- 把重试逻辑封装进 GOTO retry_label → 语法报错，跨 TRY/CATCH 边界不被允许

正确捕获点：调用方批处理必须包裹重试逻辑

唯一可控的重试入口，在外部 T-SQL 批处理中（如 SSMS 查询窗口、SQL Agent 作业步骤、或应用拼接的完整语句）：

必须用 WHILE 循环 + EXEC 调用目标存储过程
每次执行后立刻检查 ERROR_NUMBER() = 1205
不要捕获所有错误统一重试，否则可能掩盖真实问题（比如主键冲突、权限不足）

示例结构：

超级简历WonderCV

一款AI办公效率工具，主要用于免费求职简历模版下载制作，应届生职场人必备简历制作神器，适合需要提升相关任务效率的用户。

下载

DECLARE @retry INT = 0;
WHILE @retry <p>注意：<code>ROLLBACK TRANSACTION</code> 不需要显式写——SQL Server 已自动回滚；再写会触发 “The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION”。</p><hr><h3>应用层重试比 SQL 层更可靠</h3>

存储过程无法保留上下文，而应用代码（C#、Java、Python）可以：
- 控制重试间隔（指数退避）
- 记录每次失败的参数与时间戳
- 在重试前校验业务状态（比如订单是否已被取消）
避免在 SQL 层做嵌套 EXEC 或递归调用，容易放大锁持有时间
如果必须用 SQL 层重试，确保参数值不变（如自增 ID、GETDATE() 结果），否则可能引发数据不一致

真正难的不是写重试代码，而是确认：这次失败真的是死锁，而不是因索引缺失导致全表扫描锁升级，或者事务里混入了外部依赖（如链接服务器）拖长了持锁时间。