开启innodb_print_all_deadlocks并分析SHOW ENGINE INNODB STATUS中的LATEST DETECTED DEADLOCK部分，可定位死锁原因，重点关注事务加锁顺序、锁类型及SQL执行逻辑，结合应用代码优化事务范围与访问顺序，减少资源竞争。
在 MySQL 中定位死锁问题，关键在于理解死锁产生的原因，并利用系统提供的工具快速获取死锁信息。InnoDB 存储引擎会自动检测死锁并回滚其中一个事务，但开发者需要主动分析日志来排查根本原因。
开启死锁日志记录
MySQL 默认不会将死锁信息打印到错误日志中，需手动开启：
SET GLOBAL innodb_print_all_deadlocks = ON;开启后，所有死锁事件都会被记录到错误日志文件中，便于后续分析。建议在生产环境中长期开启，方便问题追溯。
查看最近一次死锁详情
使用以下命令查看最近发生的死锁信息：
SHOW ENGINE INNODB STATUS\G输出内容中包含一个 LATEST DETECTED DEADLOCK 部分，其中详细记录了：
- 两个（或多个）事务的线程ID和等待时间
- 每个事务已经持有的锁
- 每个事务正在等待的锁
- 导致死锁的SQL语句
- 事务的加锁顺序和资源竞争关系
通过这部分信息，可以清楚看到哪个事务持有了什么锁，另一个事务又在等待什么资源，从而形成循环等待。
分析死锁日志中的关键信息
重点关注以下几个方面：
- 事务开始时间与执行语句：判断事务是否过长，是否未及时提交
- 锁类型与行记录：是行锁、间隙锁还是Next-Key锁？涉及哪些索引？
- 加锁顺序不一致：常见原因是不同事务以不同顺序访问表或索引
- 缺失索引导致全表扫描：可能引发大量不必要的锁，增加死锁概率
例如：事务A先更新用户表再更新订单表，事务B反过来先更新订单表再更新用户表，就容易因加锁顺序冲突导致死锁。
结合应用代码进行排查
拿到死锁SQL后，回到应用层检查对应事务逻辑：
- 事务是否包含了不必要的操作？尽量缩短事务范围
- 是否存在循环调用或嵌套事务？
- 是否可以通过统一访问顺序避免资源竞争？
- 是否能异步处理部分更新，减少同步事务持有锁的时间？
同时检查是否有批量操作未分批执行，导致长时间持有多个行锁。
基本上就这些。定期关注 SHOW ENGINE INNODB STATUS 输出，配合监控和日志收集，能有效定位和减少死锁发生。
