MySQL 事务死锁怎么定位：SHOW ENGINE INNODB STATUS 与锁等待图

线上订单接口偶尔返回1213错误，大部分时候重试一下请求就成功了，很多人第一反应会误以为是数据库临时抽风。排查的时候最先要确认的是，是不是有两个事务反向持有订单行和库存行的锁，一旦锁等待形成闭环，InnoDB会主动选开销更小的那个事务回滚，应用侧只能看到报错结果，根本看不到完整的冲突过程。

先把 1213 还原成一条锁等待环

假设下单事务要扣减 inventory，再更新 orders；取消订单事务则先锁订单，再释放库存。两个请求同时进入时，可能出现下面的顺序：

T1 等 T2 放开订单，T2 又等 T1 放开库存，等待关系回到了起点。InnoDB 发现环路后会选择代价较小的事务作为受害者回滚，应用因此收到 ERROR 1213 (40001): Deadlock found when trying to get lock。

SHOW ENGINE INNODB STATUS：先看最近一次完整现场

死锁刚触发、数据库连接还没释放的时候，先把完整的原始输出存下来，别只抄一段错误摘要就完事：

SHOW ENGINE INNODB STATUS\G

重点找 ------------------------ LATEST DETECTED DEADLOCK ------------------------。下面两段事务记录要对照看四件事：事务 ID、已经持有的锁、等待的锁，以及最后被回滚的事务。记录里的表名、索引名和锁模式，比“某接口超时”更接近根因。

*** (1) TRANSACTION:
TRANSACTION 84521, ACTIVE 0 sec starting index read
*** WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS ... table `shop`.`orders` index `PRIMARY` ... lock_mode X waiting

*** (2) TRANSACTION:
TRANSACTION 84522, ACTIVE 0 sec updating
*** HOLDS THE LOCK(S):
RECORD LOCKS ... table `shop`.`inventory` index `PRIMARY` ... lock_mode X
*** WE ROLL BACK TRANSACTION (2)

不要把 WE ROLL BACK TRANSACTION 当成“第二个请求一定有 bug”。它只表示本次冲突中 InnoDB 选了 T2；真正的判断仍然是比较两条事务的访问顺序。

现场还在持续时，用 performance_schema 对上连接和 SQL

SHOW ENGINE INNODB STATUS 是最近一次快照；如果锁等待还在发生，可以查当前等待关系。不同 MySQL 小版本的字段可能略有差异，先用 DESCRIBE 确认视图字段，再执行查询。

SELECT
  waiting.ENGINE_TRANSACTION_ID AS waiting_trx,
  waiting.OBJECT_SCHEMA AS waiting_schema,
  waiting.OBJECT_NAME AS waiting_table,
  blocking.ENGINE_TRANSACTION_ID AS blocking_trx,
  blocking.OBJECT_NAME AS blocking_table
FROM performance_schema.data_lock_waits AS waits
JOIN performance_schema.data_locks AS waiting
  ON waits.REQUESTING_ENGINE_LOCK_ID = waiting.ENGINE_LOCK_ID
JOIN performance_schema.data_locks AS blocking
  ON waits.BLOCKING_ENGINE_LOCK_ID = blocking.ENGINE_LOCK_ID;

这条查询告诉你“谁在等谁”，但不一定直接给出业务接口名。要把事务映射回连接和 SQL，还需要结合 events_transactions_current、threads 或应用连接日志中的线程 ID。诊断记录至少保留：发生时间、事务 ID、线程 ID、表/索引、SQL 模板和最终回滚方。

修复重点不是关闭检测，而是统一取锁顺序

最稳妥的调整方式是，让下单和取消这两条业务路径的加锁顺序完全对齐，要么都先锁订单行再锁库存行，要么都先锁库存行再锁订单行。选哪个顺序本身没有对错，只要同一片业务范围内保持一致就好。以「先锁订单、后锁库存」的方案举例：

START TRANSACTION;
SELECT status FROM orders WHERE id = 42 FOR UPDATE;
SELECT stock FROM inventory WHERE id = 7 FOR UPDATE;
UPDATE inventory SET stock = stock - 1
 WHERE id = 7 AND stock > 0;
UPDATE orders SET status = 'paid' WHERE id = 42;
COMMIT;

同时把事务里不需要持锁完成的网络调用、日志上报和复杂计算移到提交之后。库存扣减要检查受影响行，订单状态更新要带上允许的前置状态；这样即使发生回滚或重试，也不容易把业务状态推进两次。

innodb_print_all_deadlocks=ON 可以把每次死锁写入错误日志，便于短时间复现和统计；它会增加日志量，排查窗口结束后应按运维策略关闭或调整采集。

应用重试要有边界：只处理可重试的事务失败

别直接把1213和1205这两个错误当成所有数据库异常的通用重试触发条件。应用层要精准匹配明确的 SQLSTATE/错误码，设置合理的重试次数上限加上退避策略，每次重试都必须重新开启独立事务，不能继续使用已经被InnoDB回滚过的旧连接上下文。

for attempt := 0; attempt 

重试前还要确认写入具备幂等边界，例如订单状态从 pending 到 paid 只能成功一次。否则死锁解决了，重复扣库存的问题却会被放大。

最小验证：证明死锁风险下降，而不是暂时没报错

修复后先在低流量环境用两条并发路径压测，再观察一段真实流量。验收至少覆盖几个维度：

• 同一时间窗口的 1213 次数和错误日志死锁记录是否下降。
• 订单、库存的事务耗时 P95 是否因扩大锁范围而上升。
• 重试次数、最终失败数和库存受影响行是否符合业务预期。
• 再次出现冲突时，能否从事务 ID、线程 ID 追到接口和 SQL 模板。

如果死锁数量下降但事务耗时明显变长，不要急着收尾；统一顺序可能只是把锁冲突变成了更长的排队。此时要继续缩短事务执行路径、减少锁覆盖范围，还要检查索引是否让更新操作准确命中目标行。

常见问题

MySQL 死锁和锁等待超时是一回事吗？

不是。死锁是等待关系形成环后被检测到，主动回滚其中一个事务；锁等待超时是等待超过阈值仍未拿到锁。两者都可能需要重试，但定位证据和修复方向不完全相同。

可以关闭 InnoDB 死锁检测来避免 1213 吗？

不建议把关闭死锁检测当作通用修复方案。高并发场景可以基于官方参数文档评估检测开销，但关闭后通常只能等超时触发，故障反馈会更慢，应用也更难快速恢复。

为什么统一加锁顺序后还会有死锁？

可能仍有另一条代码路径访问表的顺序不同，也可能涉及辅助索引、范围锁或触发器。要回到最新死锁现场，逐条对照持锁与等待的索引名称排查。

重试三次就能保证订单成功吗？

不能。重试只是降低瞬时冲突对用户的影响，最终仍要返回明确结果，并用幂等键、状态机和库存受影响行保证业务不会重复执行。

小结

定位 MySQL 事务死锁时，先保存 SHOW ENGINE INNODB STATUS 的完整现场，再用 performance_schema 补上当前等待关系和连接映射。修复围绕统一加锁顺序、缩短持锁时间和可控重试展开，最后用死锁计数、延迟、重试与业务数据四组指标验收。这样处理，1213 才不再只是被重试逻辑遮住的一行错误。