首先通过SHOW ENGINE INNODB STATUS查看最近死锁信息，分析事务加锁顺序和SQL语句，定位循环等待原因；再启用innodb_print_all_deadlocks记录所有死锁至错误日志；常见死锁原因为加锁顺序不一致、间隙锁冲突、无索引扫描及长事务；建议统一加锁顺序、添加索引、缩短事务、重试回滚事务并合理设置隔离级别。
在 MySQL 中排查事务死锁，关键在于获取死锁的详细信息并分析其成因。InnoDB 存储引擎提供了自动检测死锁的能力，并会回滚其中一个事务来打破死锁。但作为开发者或 DBA，需要主动排查和优化以减少死锁发生。
查看最近一次死锁信息
MySQL 提供了 SHOW ENGINE INNODB STATUS 命令，可以查看最近一次死锁的详细信息：
SHOW ENGINE INNODB STATUS\G在输出结果中查找 LATEST DETECTED DEADLOCK 部分，这里会显示：
- 死锁发生的时间
- 两个（或多个）事务的线程 ID 和等待状态
- 每个事务已经持有的锁
- 每个事务正在等待的锁
- 导致死锁的 SQL 语句
- 事务的隔离级别
通过这部分内容，可以清晰看出是哪几个事务、操作了哪些表和行、按什么顺序加锁导致了循环等待。
启用死锁日志记录（innodb_print_all_deadlocks）
默认情况下，只有最近一次死锁会被记录在 SHOW ENGINE INNODB STATUS 中。为了长期监控，建议开启将所有死锁记录到错误日志的功能：
SET GLOBAL innodb_print_all_deadlocks = ON;
开启后，每次发生死锁，MySQL 都会将完整的死锁信息写入错误日志文件（通常在数据目录下的 .err 文件中）。这有助于后续分析和审计。
分析死锁常见模式
从死锁日志中识别出以下常见场景：
- 不同顺序加锁：两个事务以相反顺序更新同一组行。例如事务 A 先更新 row1 再 row2，事务 B 先更新 row2 再 row1，容易形成死锁。
- 间隙锁冲突：在可重复读（REPEATABLE READ）隔离级别下，范围查询会加间隙锁，多个事务对同一范围加锁可能引发死锁。
- 未使用索引导致表级扫描：UPDATE 或 DELETE 条件未命中索引，InnoDB 可能需要扫描大量行并加锁，增加锁冲突概率。
- 长事务持有锁时间过长：事务执行时间越长，持锁时间越久，与其他事务冲突的可能性越高。
减少死锁的建议
基于分析结果，可采取以下措施降低死锁概率：
- 确保所有事务以相同顺序访问表和行（如总是按主键升序更新）
- 为查询条件添加合适索引，避免全表扫描和不必要的锁
- 缩短事务执行时间，尽快提交或回滚
- 在应用层重试被回滚的事务（通常最多重试几次）
- 考虑降低隔离级别（如改为 READ COMMITTED），减少间隙锁使用
基本上就这些。定期检查死锁日志，结合业务逻辑分析 SQL 执行路径，能有效定位和解决 MySQL 死锁问题。
