INFORMATION_SCHEMA.INNODB_TRX是死锁诊断首选表，需筛选trx_state='LOCK WAIT'并按trx_started升序排查；trx_state='RUNNING'且COMMAND='Sleep'的未提交事务更危险；INNODB_LOCK_WAITS在5.7中不可靠，应结合INNODB_LOCKS和SHOW ENGINE INNODB STATUS定位真实阻塞者。
查 INNODB_TRX 找出活跃但卡住的事务
死锁发生时，INFORMATION_SCHEMA.INNODB_TRX 是第一张必须看的表。它能告诉你哪些事务正在运行、状态是否为 LOCK WAIT、开始时间有多久、执行了什么语句。
重点筛选：SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_state = 'LOCK WAIT' —— 这些是已明确在等锁的事务；再补一句 ORDER BY trx_started ASC，越早开始的越可能是“元凶”或长期未提交的 Sleep 事务。
注意：trx_state = 'RUNNING' 且 COMMAND = 'Sleep' 的记录更危险——它表面休眠，实则没提交，一直占着锁。这类事务常来自连接池归还连接前忘了 COMMIT 或 ROLLBACK。
用 INNODB_LOCK_WAITS 关联等待与持有者
INNODB_LOCK_WAITS 表本意是直接映射“谁在等谁”，但在 MySQL 5.7 中它字段精简、关联不稳定，经常查不到完整链路，甚至返回空。不能单独依赖它定位阻塞源头。
更可靠的做法是：先从 INNODB_TRX 拿到 waiting_trx_id，再手动去 INNODB_LOCKS 查它等待的锁（lock_trx_id = waiting_trx_id），然后根据 lock_space + lock_page + lock_rec 去反推被哪个事务持有的同位置锁。
常见陷阱：blocking_trx_id 字段在 5.7 中可能为空，或指向一个早已结束但未清理干净的 trx_id；此时必须回到 SHOW ENGINE INNODB STATUS\G 的 TRANSACTIONS 段落里找真实持有者。
结合 INNODB_LOCKS 看锁类型和范围
INNODB_LOCKS 在 5.7 中仍可用，它暴露每把锁的细节：类型（RECORD / GAP / INSERT_INTENTION）、索引名、锁定的记录位置（lock_rec）、事务 ID（lock_trx_id）。
关键判断点：
-
lock_mode是X还是S？INSERT ... ON DUPLICATE KEY UPDATE在 RR 隔离级别下可能同时持 S 锁和 X 锁 -
lock_type = 'RECORD'且lock_index = 'PRIMARY'表示锁在主键上；若为二级唯一索引（如UNIQUE KEY `num_index`），说明冲突发生在唯一键检查环节 - 出现大量
lock_mode = 'GAP'或'INSERT_INTENTION'，基本可断定是间隙锁竞争，尤其在无索引 WHERE 条件或并发 INSERT 场景下
别漏掉 SHOW ENGINE INNODB STATUS 的实时快照
SHOW ENGINE INNODB STATUS\G 是 MySQL 5.7 中最权威的死锁诊断入口，它的 LATEST DETECTED DEADLOCK 段落会完整打印两个事务的锁持有与等待关系，包括索引名、记录值、锁模式，甚至哪一行 SQL 触发了锁请求。
操作建议：
- 执行后立刻复制整段输出，不要只扫一眼——死锁日志只保留最近一次
- 搜索关键词：
WAITING FOR THIS LOCK TO BE GRANTED（等待方）、HOLDS THE LOCK(S)（持有方） - 对比
trx_id和mysql thread id，再回查PROCESSLIST确认该线程当前 SQL 和状态（比如State: Locked或Sending data） - 如果
INNODB_LOCK_WAITS查不到阻塞者，这里一定能定位到真实持有锁的trx_id
真正容易被忽略的是：很多 DBA 只查表、不看 status 输出，结果在 INNODB_LOCK_WAITS 里反复刷空结果，却没意识到 5.7 的这张表已经“半残废”了——它只是个辅助视图，不是真相本身。
