答案是通过SHOW ENGINE INNODB STATUS查看LATEST DETECTED DEADLOCK部分，分析事务加锁顺序和sql语句，结合performance_schema表定位死锁原因，并启用innodb_print_all_deadlocks记录日志，规范事务操作顺序以降低死锁概率。

在 mysql 中定位死锁事务，关键在于理解死锁产生的机制，并利用系统提供的工具和日志信息快速排查。InnoDB 存储引擎具备自动检测死锁的能力，并会回滚其中一个事务来解除死锁，但开发者仍需主动分析原因以优化应用逻辑。

启用并查看死锁日志

InnoDB 会在发生死锁时将详细信息记录到错误日志或通过 SHOW ENGINE INNODB STATUS 输出。这是最直接的定位方式。

– 执行命令：

SHOW ENGINE INNODB STATUSG

结果中的 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 的输出中，观察两个事务的加锁顺序：

如知AI笔记

如知笔记——支持markdown的在线笔记，支持ai智能写作、AI搜索，支持DeepseekR1满血大模型

27

查看详情

• 事务 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 操作的顺序，尽量缩短事务执行时间，能显著降低死锁发生概率。一旦出现频繁死锁，重点查并发更新相同数据集的业务逻辑。不复杂但容易忽略。