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