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，锁住过多记录，增加交叉概率