直接查 performance_schema.data_locks 定位 Gap Lock：LOCK_MODE 为 GAP 或 NEXT-KEY 且 LOCK_DATA 显示开区间（如 (5,10)）即确认被间隙锁阻塞；若 LOCK_DATA 为空，则大概率因缺失主键或索引导致全表隐式聚簇索引扫描。
怎么确认 INSERT 正被 Gap Lock 卡住
别靠超时日志猜，直接查系统表定位锁源。Gap Lock 不报错、不提示区间，只让 INSERT 无限等待或最终抛出 Lock wait timeout exceeded。
- 先看谁在等锁：
SELECT * FROM information_schema.INNODB_TRX WHERE TRX_STATE = 'LOCK WAIT';，拿到阻塞事务的TRX_ID - 再查它等什么锁：
SELECT * FROM performance_schema.data_locks WHERE LOCK_TRX_ID = 'xxx';（把 xxx 替换为上一步的 ID） - 重点过滤：
LOCK_MODE是GAP或NEXT-KEY，且LOCK_DATA显示类似(5, 10)这样的开区间——说明插入值落在这个间隙里被拦住了 - 如果
LOCK_DATA是NULL或空，大概率是表没主键/没索引，InnoDB 用隐式聚簇索引扫全表，间隙锁覆盖整个范围
哪些 INSERT 场景最容易触发 Gap Lock 阻塞
不是所有 INSERT 都会惹上间隙锁，关键看它是否“被迫扫描范围”。
-
INSERT INTO t VALUES (5, 'x')这种主键/唯一索引等值插入，只加记录锁，不触发间隙锁 -
INSERT ... SELECT或带子查询的插入，InnoDB 可能退化为隐式聚簇索引扫描，间隙范围难控 - 目标表没有主键或合适索引时，InnoDB 用隐式聚簇索引，间隙锁覆盖整个范围
- 在非唯一二级索引字段（如
status）上执行了WHERE status = 'pending' FOR UPDATE后紧接INSERT，新行可能落在已被锁住的区间内
用 SHOW ENGINE INNODB STATUS 快速抓现场
这是线上卡顿时最实用的第一步，不用连 performance_schema，也不依赖 MySQL 版本兼容性。
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 执行
SHOW ENGINE INNODB STATUS\G，搜索TRANSACTIONS段落 - 找状态为
LOCK WAIT的事务，看它的WAITING FOR THIS LOCK TO BE GRANTED行 - 如果出现
lock_mode X locks gap before rec，基本坐实是 Gap Lock 阻塞 - 同时注意
LATEST DETECTED DEADLOCK段——若存在，说明已发生死锁，InnoDB 自动回滚了一个事务，但根源仍是间隙锁 + 插入意向锁循环等待
为什么 INNODB_LOCK_WAITS 在 Gap 场景下容易误导
MySQL 5.7 中 INNODB_LOCK_WAITS 不记录 GAP 锁的等待链，只反映 RECORD 级别的直接阻塞。这意味着：你查不到谁在持有一个 GAP 锁，却看到另一个事务在等锁——它其实是在等插入意向锁（INSERT_INTENTION），而这个意向锁又被 Gap Lock 拦住了。
- 典型表现：事务 A 持有
lock_mode = X+lock_type = RECORD，事务 B 等待lock_mode = X+lock_type = INSERT_INTENTION，且lock_page相同但lock_rec不同 → 就是 Gap Lock + 插入意向锁的循环等待 - 此时查
INNODB_LOCK_WAITS只能看到事务 B 等待事务 A，但事务 A 根本没在等任何 RECORD 锁——它只是锁了一段空白间隙 - 真正要盯的是
performance_schema.data_locks中LOCK_MODE和LOCK_DATA的组合，而不是等待关系本身
Gap Lock 的麻烦在于它不显式报错，也不暴露锁区间；排查时最容易忽略的是 LOCK_DATA 为空或 NULL 的情况——那往往意味着索引缺失，而不是语句写错了。
