MySQL 8.4 InnoDB 死锁怎么留证：SHOW ENGINE、错误日志与重试验收

订单服务偶尔报事务回滚错，应用日志往往只留了一行模糊的错误码。这时候别直接把它当成普通锁等待处理：MySQL 8.4 的 InnoDB 会自动检测事务死锁，主动选中其中一个事务回滚来打破等待环路，如果应用层没专门识别死锁场景做重试，终端用户看到的就是直接请求失败。

排查 InnoDB 死锁要同时留三类证据：用 SHOW ENGINE INNODB STATUS 看最近一次现场，用 innodb_print_all_deadlocks 把后续每次现场写入错误日志，再用事务顺序和重试结果确认修复是否有效。

先确认这是死锁，不是单向锁等待

死锁至少有两个事务互相持有对方后续操作需要的锁，形成资源等待闭环；单向锁等待只是一方持锁、另一方在队列里正常等待。两者的根因和处理动作完全不同。可以先核对应用返回的错误类型，再到数据库侧拉取最近的死锁现场：

SHOW ENGINE INNODB STATUS\G

输出里重点找 LATEST DETECTED DEADLOCK，接着往下捋两个事务的 WAITING FOR THIS LOCK 和 HOLDS THE LOCK(S)。不要只截取开头的错误提示，真正有排查价值的是涉及的表名、索引名、事务正在执行的SQL，以及最后被判定回滚的受害事务标识。

把最近一次现场保存下来再分析

SHOW ENGINE INNODB STATUS 展示的永远是最近一次死锁的详情，新产生的死锁会直接覆盖旧的现场记录。所以排查时发现问题，先把完整原始输出存好，不要边刷新边凭零碎印象修改SQL：

mysql -N -e 'SHOW ENGINE INNODB STATUS\G' \
  > /tmp/innodb-status-$(date +%Y%m%d%H%M%S).txt

之后顺着日志里的事务ID和对应SQL还原操作顺序。比如库存扣减事务先锁 inventory 再锁 orders，但订单取消事务刚好反过来操作，就很容易形成A等B、B等A的等待环路。这里的判断必须以输出里明确的持锁、等待锁记录为依据，不能只靠“两个接口同时更新”这类推测下结论。

频繁发生时打开所有死锁日志

如果业务峰值时段每小时会出现多次死锁，只靠最后一次的现场信息根本不够用。可以在约定的故障观察窗口临时开启全量死锁记录：

SET GLOBAL innodb_print_all_deadlocks = ON;
SHOW GLOBAL VARIABLES LIKE 'innodb_print_all_deadlocks';

这个变量是全局动态变量，开启后所有死锁的完整详情都会写入mysqld错误日志。日志的实际存储路径由 log_error 等服务配置决定，不能直接假设是某个固定文件名。收集完足够的故障样本之后，按照内部变更约定把配置改回关闭状态：

SET GLOBAL innodb_print_all_deadlocks = OFF;

日志里涉及业务数据的事务访问表、索引和语句参数要先做脱敏处理，再交给后续排查人员。生产环境不要为了多留证就无限期开启这个配置，尤其是死锁本身已经发生得很频繁的场景，错误日志的体积会快速膨胀，占用磁盘空间。

修复优先统一访问顺序，再谈参数调整

最常见的结构性修复方案，是让涉及多张表的所有事务都按完全相同的顺序访问资源。比如订单和库存都需要更新的场景，就明确规定所有业务路径都先锁 orders，再锁 inventory，反过来也可以，但是绝对不能让不同业务分支各自定访问顺序。

同时检查 UPDATE ... WHERE、SELECT ... FOR UPDATE 的过滤列上有没有建合适的索引。缺少索引会扩大SQL的扫描范围和锁定范围，大幅提升锁冲突的概率。不过加索引也要结合实际执行计划和写入侧的性能成本评估，不能把所有死锁问题都简单归因于少建了一个索引。

应用重试要验证受害事务是否可安全重放

InnoDB自动选中受害事务回滚之后，应用层通常会收到明确的死锁错误。重试逻辑要放在整个事务的外部边界，不能只重复执行最后报错的那一条SQL：

for attempt := 1; attempt 

做重试之前要先确认，事务里的所有副作用操作都包在数据库事务范围内，消息发送、第三方扣款、外部HTTP调用这类操作不能因为重试重放出现重复执行的问题。可以用幂等键、唯一约束或者outbox模式，把外部系统的副作用操作和数据库事务提交完全解耦。验收环节至少要覆盖三种结果场景：正常并发冲突触发回滚、第一次回滚后重试成功、达到最大重试上限退出。

常见问题：死锁排查的几个误区

死锁是不是把锁等待超时调大就能解决？

不是。InnoDB默认就会主动检测死锁并回滚其中一个事务，锁等待超时参数主要用来处理检测不到死锁或者非典型的长等待场景。单纯调大超时时间只会让普通锁等待拖得更久，完全消除不了事务访问顺序冲突带来的死锁根因。

SHOW ENGINE INNODB STATUS 能看到所有历史死锁吗？

不能，它只会保留最近一次死锁的现场记录。需要连续留存多份死锁样本时，开启 innodb_print_all_deadlocks，同时做好错误日志的采集和保留策略。

偶发一次死锁是不是一定要改表结构？

不一定。并发写入量高的系统里偶发死锁属于正常现象，重点是应用能不能正确识别死锁异常、完成回滚后执行有限次数的安全重试。只有当死锁发生频率持续上升、重试大量失败，或者日志明确显示不同事务资源访问顺序完全不一致时，才需要优先调整事务结构。

为什么同样的SQL有时成功、有时死锁？

死锁的触发完全取决于当前的并发时序、不同事务已经持有的锁、事务整体的执行时长。单独单线程执行这段SQL根本不可能出现等待环路，必须结合两个冲突事务的持锁、等待锁信息，复现真实的并发场景才能复现问题。

一份从现场到验收的检查清单

1. 保存 SHOW ENGINE INNODB STATUS\G 完整原始输出，记录对应的故障时间和实例标识。
2. 定位两个冲突事务分别持有什么锁、等待什么锁、最后哪一个被判定为回滚对象。
3. 必要时短期开启 innodb_print_all_deadlocks，从错误日志收集多份死锁样本。
4. 统一跨多表事务的资源访问顺序，复查锁定条件对应的索引合理性和事务执行时长。
5. 在事务外部边界实现有限次数的安全重试，完整验收回滚、重试成功、幂等校验、达到重试上限所有分支逻辑。

排查死锁的目标不是要求数据库永远不回滚事务，而是让所有冲突都能找到可解释的根因，失败请求可以安全重试，调整修复的每一步都有完整证据支撑。