首先通过SHOW ENGINE INNODB STATUS查看最近死锁信息，分析事务加锁顺序和sql语句，定位循环等待原因；再启用innodb_print_all_deadlocks记录所有死锁至错误日志；常见死锁原因为加锁顺序不一致、间隙锁冲突、无索引扫描及长事务；建议统一加锁顺序、添加索引、缩短事务、重试回滚事务并合理设置隔离级别。

在 mysql 中排查事务死锁，关键在于获取死锁的详细信息并分析其成因。InnoDB 存储引擎提供了自动检测死锁的能力，并会回滚其中一个事务来打破死锁。但作为开发者或 dba，需要主动排查和优化以减少死锁发生。

查看最近一次死锁信息

MySQL 提供了 SHOW ENGINE INNODB STATUS 命令，可以查看最近一次死锁的详细信息：

SHOW ENGINE INNODB STATUSG

在输出结果中查找 LATEST DETECTED DEADLOCK 部分，这里会显示：

• 死锁发生的时间
• 两个（或多个）事务的线程 ID 和等待状态
• 每个事务已经持有的锁
• 每个事务正在等待的锁
• 导致死锁的 SQL 语句
• 事务的隔离级别

通过这部分内容，可以清晰看出是哪几个事务、操作了哪些表和行、按什么顺序加锁导致了循环等待。

启用死锁日志记录（innodb_print_all_deadlocks）

默认情况下，只有最近一次死锁会被记录在 SHOW ENGINE INNODB STATUS 中。为了长期监控，建议开启将所有死锁记录到错误日志的功能：

简篇AI排版

AI排版工具，上传图文素材，秒出专业效果！

134

查看详情

SET GLOBAL innodb_print_all_deadlocks = ON;

开启后，每次发生死锁，MySQL 都会将完整的死锁信息写入错误日志文件（通常在数据目录下的 .err 文件中）。这有助于后续分析和审计。

分析死锁常见模式

从死锁日志中识别出以下常见场景：

• 不同顺序加锁：两个事务以相反顺序更新同一组行。例如事务 A 先更新 row1 再 row2，事务 B 先更新 row2 再 row1，容易形成死锁。
• 间隙锁冲突：在可重复读（REPEATABLE READ）隔离级别下，范围查询会加间隙锁，多个事务对同一范围加锁可能引发死锁。
• 未使用索引导致表级扫描：UPDATE 或 delete 条件未命中索引，InnoDB 可能需要扫描大量行并加锁，增加锁冲突概率。
• 长事务持有锁时间过长：事务执行时间越长，持锁时间越久，与其他事务冲突的可能性越高。

减少死锁的建议

基于分析结果，可采取以下措施降低死锁概率：

• 确保所有事务以相同顺序访问表和行（如总是按主键升序更新）
• 为查询条件添加合适索引，避免全表扫描和不必要的锁
• 缩短事务执行时间，尽快提交或回滚
• 在应用层重试被回滚的事务（通常最多重试几次）
• 考虑降低隔离级别（如改为 READ COMMITTED），减少间隙锁使用

基本上就这些。定期检查死锁日志，结合业务逻辑分析 SQL 执行路径，能有效定位和解决 MySQL 死锁问题。