MySQL InnoDB 死锁后为什么只回滚一个事务

MySQL InnoDB 检测到死锁后，通常只回滚其中一个事务，这是为了用最小代价打破等待环，而不是因为另一个事务“更正确”。被选中的事务叫受害事务（victim）：它的锁被释放，等待它的另一个事务就能继续。默认情况下，InnoDB 会优先选择修改行数较少、回滚成本相对低的事务，但应用不能依赖某个固定会话永远成为受害者。

为什么典型死锁只需要回滚一个事务

假设事务 T1 先锁住行 A，再请求行 B；事务 T2 先锁住行 B，再请求行 A。此时 T1 等 T2，T2 又等 T1，任何一个事务都无法靠“继续等待”走出去。只要回滚其中一个事务，它持有的行锁就会释放，另一个事务便能获得所需锁并完成。

所以回滚两个事务通常是多余的：它会扩大业务失败范围，增加 undo 处理量，还让本来可以成功的一方丢失工作。InnoDB 的默认死锁检测会在等待图中发现这种环，并选一个事务作为 victim。这里的“一个”是典型死锁解除策略，不表示所有复杂锁等待异常都永远只影响一个事务；如果关闭了死锁检测，处理方式会转向 innodb_lock_wait_timeout。

InnoDB 怎么判断谁更适合被回滚

官方文档把受害事务选择描述为“尽量选择小事务”。这里的大小主要按事务已经插入、更新或删除的行数衡量。一个刚更新一行、但恰好形成闭环的事务，通常比已经改动大量数据的事务更适合回滚，因为撤销工作更少，释放锁也更快。

这不是一个可以写进业务代码的稳定排序规则。事务开始时间、连接编号、SQL 文本长度都不能直接推出谁会成为 victim；锁数量也不等于修改行数。排查时应以死锁报告里明确的回滚提示为准，而不要看到某个事务“看起来更小”就下结论。

如何从日志确认谁被回滚

先看最近一次死锁报告，不要只看应用日志里的一句“Deadlock found”。在有权限的管理会话中执行：

SHOW ENGINE INNODB STATUS\G
-- 查看 LATEST DETECTED DEADLOCK，确认涉及的事务、锁和被回滚者

报告中的 LATEST DETECTED DEADLOCK 会列出参与事务尝试执行的语句、各自持有或等待的锁，以及 InnoDB 为打破死锁选择回滚的事务。若问题偶发，这条记录只能保留最近一次；排障期间可以临时打开所有死锁日志：

SET GLOBAL innodb_print_all_deadlocks = ON;
-- 只在排障期打开，让每次死锁写入错误日志

SET GLOBAL innodb_print_all_deadlocks = OFF;
-- 排障结束后关闭，避免日志持续增长

需要观察仍在等待的锁时，再结合 INNODB_TRX、data_locks 和 data_lock_waits。前者能看到事务状态与当前语句，后两者能把请求锁和阻塞锁对应起来。它们用于还原现场，最终是否回滚仍以死锁报告为准。

应用收到 1213 后应该怎么处理

死锁回滚的是整个事务，不是只失败的那一条 SQL。应用捕获 ERROR 1213 或 SQLSTATE 40001 后，应先结束当前事务，再从事务入口重新执行全部业务动作。下面是伪代码式 PHP 示例，重点是重试边界，不是把单条 UPDATE 重复发送：

for ($attempt = 1; $attempt beginTransaction();
        // 事务内的读取、修改和校验必须作为一个完整业务单元重做
        transferBalance($db, $fromId, $toId, $amount);
        $db->commit();
        break;
    } catch (PDOException $e) {
        if ($db->inTransaction()) {
            $db->rollBack(); // 先释放当前连接上的事务状态
        }
        $retryable = str_contains($e->getMessage(), '1213')
            || $e->getCode() === '40001';
        if (!$retryable || $attempt === 3) {
            throw $e; // 非死锁错误或达到上限时交给上层处理
        }
        usleep($attempt * 50000); // 退避，避免立刻再次撞上同一批锁
    }
}

重试必须有次数上限，并配合幂等业务键或状态检查，避免网络重试和数据库重试叠加。降低死锁概率时，优先统一多表、多行操作的加锁顺序，缩短事务，避免交互式会话长时间不提交，再用合适索引减少扫描和持锁范围。

相关问题

死锁和普通锁等待有什么区别？

普通锁等待只有阻塞关系，持锁事务结束后等待者能继续；死锁形成环，必须回滚至少一个事务或等待超时处理。

为什么不能只重试死锁时失败的那条 SQL？

因为 victim 的整个事务已经回滚，前面完成的更新也不再存在。只重试当前语句可能丢失业务上下文，应该从事务入口完整重做。

修改隔离级别能彻底消除死锁吗？

不能。隔离级别主要改变读行为，写入和锁顺序仍可能形成环。先检查加锁顺序、事务长度和索引，再评估是否需要调整隔离级别。

把 innodb_lock_wait_timeout 调大能解决死锁吗？

不能把它当成根治手段。默认启用死锁检测时，InnoDB 会尽快选择 victim；关闭检测后才更多依赖超时回滚。调大超时可能让请求等待更久。