在 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 死锁问题。
