答案是通过SHOW ENGINE INNODB STATUS查看LATEST DETECTED DEADLOCK部分，分析事务加锁顺序和SQL语句，结合performance_schema表定位死锁原因，并启用innodb_print_all_deadlocks记录日志，规范事务操作顺序以降低死锁概率。
在 MySQL 中定位死锁事务，关键在于理解死锁产生的机制，并利用系统提供的工具和日志信息快速排查。InnoDB 存储引擎具备自动检测死锁的能力，并会回滚其中一个事务来解除死锁，但开发者仍需主动分析原因以优化应用逻辑。
启用并查看死锁日志
InnoDB 会在发生死锁时将详细信息记录到错误日志或通过 SHOW ENGINE INNODB STATUS 输出。这是最直接的定位方式。
- 执行命令：SHOW ENGINE INNODB STATUS\G
结果中的 LATEST DETECTED DEADLOCK 部分会显示最近一次死锁的时间、涉及的两个事务、每个事务持有的锁、等待的锁以及 SQL 语句。
- 关键信息包括：- 事务 ID 和线程 ID
- 事务开始时间与执行的 SQL
- 锁类型（行锁、间隙锁等）
- 哪个事务被选为“牺牲者”被回滚
开启死锁日志记录到表
为了长期监控和分析，建议将 InnoDB 的死锁信息记录到 information_schema.innodb_lock_waits 和 performance_schema 相关表中。
- 启用参数：确保 my.cnf 中配置了：
innodb_print_all_deadlocks = ON
该设置会把每次死锁记录到 MySQL 错误日志中，便于后续审计。
分析事务执行顺序和加锁路径
从 SHOW ENGINE INNODB STATUS 的输出中，观察两个事务的加锁顺序：
- 事务 A 持有某行的 X 锁，等待事务 B 持有的另一行锁
- 事务 B 持有后者，反过来等待事务 A 的锁
典型场景是两个事务以不同顺序更新多条记录。例如：
事务1：UPDATE t SET a=1 WHERE id=1; UPDATE t SET a=1 WHERE id=2;
事务2：UPDATE t SET a=1 WHERE id=2; UPDATE t SET a=1 WHERE id=1;
这种交叉加锁极易导致死锁。
结合 performance_schema 分析锁等待
MySQL 5.7+ 提供了 performance_schema 表来实时查看锁信息。
- 查询当前锁等待：SELECT * FROM performance_schema.data_locks;
SELECT * FROM performance_schema.data_lock_waits;
通过 THREAD_ID 可关联 PROCESSLIST，找到具体连接和执行的语句。
基本上就这些。定期检查死锁日志，规范事务中 DML 操作的顺序，尽量缩短事务执行时间，能显著降低死锁发生概率。一旦出现频繁死锁，重点查并发更新相同数据集的业务逻辑。不复杂但容易忽略。
