MySQL死锁排查核心是“定位—分析—验证”三步，需通过SHOW ENGINE INNODB STATUS获取最近死锁详情，启用innodb_print_all_deadlocks记录全量日志，并结合INNODB_TRX、INNODB_LOCK_WAITS等视图分析事务与锁等待关系，再结合业务SQL还原访问顺序、索引缺失、长事务及批量操作等成因。
MySQL死锁排查核心是“定位—分析—验证”三步，关键在于快速获取死锁现场信息，并结合事务行为与锁机制判断冲突根源。不需要重启服务，也不必依赖外部工具，原生命令就能完成大部分诊断。
查看最近一次死锁详情
执行 SHOW ENGINE INNODB STATUS\G，重点查找输出中以 ------------------------ LATEST DETECTED DEADLOCK ------------------------ 开头的区块。这部分包含：
- 两个冲突事务的 ID、线程号（thread id）、执行 SQL 语句
- 每个事务持有的锁（HOLDS THE LOCK(S)）和等待的锁（WAITING FOR THIS LOCK TO BE GRANTED）
- 锁对应的表、索引名、页号、行锁范围（如 rec but not gap 表示记录锁）
- 被自动回滚的是哪个事务（InnoDB 总是回滚代价更小的那个）
开启全量死锁日志记录
仅靠 SHOW ENGINE INNODB STATUS 只能看最后一次死锁，线上高频场景需长期留痕：
- 检查当前配置：
SHOW VARIABLES LIKE 'innodb_print_all_deadlocks'; - 若值为 OFF，立即启用：
SET GLOBAL innodb_print_all_deadlocks = ON; - 日志会写入 MySQL 错误日志文件（路径由
log_error参数指定，常见如/var/lib/mysql/error.log或/usr/local/mysql/data/mysqld.local.err） - 每次死锁都会追加完整上下文，便于回溯时间线和复现频率
实时观察活跃事务与锁等待关系
当死锁频繁发生或想提前发现隐患时，主动扫描当前锁状态：
- 查正在运行的事务：
SELECT * FROM information_schema.INNODB_TRX;（关注 trx_state、trx_started、trx_query） - 查当前持有锁的信息：
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;（MySQL 8.0.18+ 已弃用，建议用performance_schema.data_locks替代） - 查锁等待链：
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;（可关联 trx 和 locks 表定位谁等谁） - 辅助判断是否锁表：
SHOW OPEN TABLES WHERE In_use > 0;
结合业务 SQL 分析死锁成因
光有日志不够，要还原执行逻辑。典型模式包括：
- 访问顺序不一致：事务 A 先更新 id=1 再更新 id=2；事务 B 反过来，极易形成循环等待
- 缺失索引导致锁升级：WHERE 条件字段无索引，InnoDB 可能对整张表加意向锁，甚至扫描大量行触发间隙锁冲突
- 长事务拖慢锁释放：一个事务开启后长时间不提交，其他事务在相同资源上等待，累积风险
- 批量操作未分页：UPDATE 大范围数据时未加 LIMIT，锁住过多记录，增加交叉概率
