应立即查应用日志中“deadlock found when trying to get lock”（错误码1213/sqlstate 40001），再执行show engine innodb status\g定位latest detected deadlock区块，比对两事务holds/waiting锁信息及回滚标识，并可开启innodb_print_all_deadlocks保留全量死锁日志。
查应用日志里有没有 Deadlock found when trying to get lock
这是最直接的信号。只要事务被 InnoDB 主动回滚，MySQL 就会向客户端返回这个标准错误码 1213（SQLSTATE: 40001），应用层通常会记录成 ERROR 级别日志。注意不是所有“事务回滚”都源于死锁——超时、语法错、约束冲突也会回滚，但只有死锁会带这串固定文本。
常见漏点：
– 日志级别设为 WARN 或更低，可能过滤掉该 ERROR
– ORM 框架（如 GORM）吞掉原始错误，只抛出泛化异常（如 Gorm.ErrRecordNotFound），需检查底层 SQL 日志或开启 logger.LogMode(logger.Info) 级别
– 应用做了重试逻辑，日志里只看到第二次成功的记录，第一次的死锁被掩盖
执行 SHOW ENGINE INNODB STATUS\G 看 LATEST DETECTED DEADLOCK
这条命令输出很长，但真正有用的就一段：以 LATEST DETECTED DEADLOCK 开头的区块。它包含最近一次死锁的完整快照，哪怕应用没捕获错误，也能从这里确认是否发生过。
重点关注三块内容：
– *** (1) TRANSACTION 和 *** (2) TRANSACTION：两个冲突事务的 ID、线程 ID、起始时间、持有锁的 SQL
– *** (1) HOLDS THE LOCK(S) 与 *** (1) WAITING FOR THIS LOCK TO BE GRANTED：明确谁持有什么锁、在等什么锁
– 最后一行 WE ROLL BACK TRANSACTION (1) 或类似表述：直接告诉你哪个事务被选中回滚了
注意：
– 这个区块只保留最近一次死锁，反复发生时旧记录会被覆盖
– 若输出里根本没有 LATEST DETECTED DEADLOCK 段，基本可排除死锁回滚（但不能排除其他原因回滚）
开 innodb_print_all_deadlocks 把每次死锁写进错误日志
临时生效：SET GLOBAL innodb_print_all_deadlocks = ON;
永久生效：在 my.cnf 的 [mysqld] 下加一行 innodb_print_all_deadlocks = 1
开启后，每次死锁都会追加到 MySQL 错误日志（路径由 log_error 变量指定，常见如 /var/log/mysql/error.log），内容和 SHOW ENGINE INNODB STATUS 里的那段几乎一致，但不会被覆盖，适合线上长期追踪。
容易忽略的细节：
– 修改 GLOBAL 变量需要 SUPER 权限，普通应用账号不行
– 错误日志文件权限要确保 MySQL 进程可写，否则开启也白开
– 日志量不大，但若每秒发生多次死锁，说明业务逻辑存在严重竞争，得优先优化，而不是只靠日志排查
结合 INNODB_TRX 和 INNODB_LOCK_WAITS 查实时阻塞链
如果死锁刚发生完，事务还没完全退出，可以用这两张表定位“正在等待锁”的活体状态：
SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'LOCK WAIT';SELECT * FROM information_schema.INNODB_LOCK_WAITS;
这两张表能告诉你：
– 哪些事务卡在 LOCK WAIT 状态（还没被回滚，还在等）
– 谁在阻塞谁（blocking_trx_id 指向另一个 trx_id）
– 对应的线程 ID 和原始 SQL（通过 trx_mysql_thread_id 关联 SHOW PROCESSLIST）
注意：
– INNODB_LOCK_WAITS 在 MySQL 8.0+ 才默认启用；5.7 需确认 performance_schema 已开启且相关 consumers 启用
– 死锁被检测并回滚后，这些表里的记录会很快清空，抓取窗口很短，适合配合监控脚本轮询
死锁回滚本身是 InnoDB 自动行为，不依赖应用显式 ROLLBACK，所以不能靠“有没有执行 ROLLBACK 语句”来判断。真正关键的是交叉验证：应用日志报错 + INNODB STATUS 有记录 + 错误日志落盘 —— 三者对上，才能确认是死锁引发的回滚。单看一个来源，很容易误判。
