INSERT被间隙锁阻塞是因为RR级别下InnoDB用Next-Key Lock防止幻读，插入时若目标位置落在其他事务已锁定的间隙范围内就会等待；需查INNODB_TRX、data_locks定位GAP/NEXT-KEY锁及范围。
INSERT被卡住但没报错，先查是不是Gap Lock在拦路
遇到INSERT语句长时间无响应、不报错也不返回，大概率是被间隙锁阻塞了。这不是死锁（InnoDB会自动回滚并记日志），而是事务在等一个它永远等不到的锁——因为持有Gap Lock的事务还没提交，甚至可能已经“忘了”自己还锁着一段空白区间。
别急着改代码，先确认现象：
- 执行
SHOW ENGINE INNODB STATUS\G，搜LOCK WAIT段，看等待类型是否含gap before rec或next-key lock - 检查
INFORMATION_SCHEMA.INNODB_TRX里有没有长时间RUNNING却没提交的事务 - 若用的是MySQL 8.0+，直接查
performance_schema.data_locks，过滤LOCK_MODE = 'GAP'或'NEXT-KEY'，重点关注LOCK_DATA字段显示的范围（如(100, 200)）是否覆盖你要插的值
唯一索引缺失或非等值查询，是Gap Lock泛滥的主因
很多人以为“只要建了索引就安全”，其实不然。Gap Lock是否触发，关键看查询是否能**精准定位到单条记录**：
- 主键或唯一索引上的等值查询（如
WHERE id = 123）只加Record Lock，不加Gap Lock - 非唯一索引上的等值查询（如
WHERE status = 'pending'）会加Gap Lock，哪怕只查出一行 -
WHERE status BETWEEN 'a' AND 'z'这类范围条件，必然触发Gap Lock，且范围越大锁越宽 - 表没主键、或插入语句没走任何索引（全表扫描），InnoDB会退化为隐式聚簇索引，Gap Lock范围极难预测
典型陷阱：SELECT * FROM order WHERE user_id = 123 FOR UPDATE，如果user_id只是普通索引，这条语句就会锁住user_id = 123对应的所有间隙，后续所有按user_id插入新订单的操作都可能被卡住。
INSERT IGNORE和ON DUPLICATE KEY UPDATE为什么也容易中招
这两个语句表面“原子”，底层仍要走完整唯一性校验流程，而校验过程本身就会申请锁：
-
INSERT IGNORE遇到唯一冲突时，会先加S锁查是否存在，再决定跳过；并发线程同时查同一UNIQUE值，就在该值对应的间隙上争抢insert intention锁 -
INSERT ... ON DUPLICATE KEY UPDATE同样分两步：先duplicate key检查（加锁），再执行update；若多个事务检查路径不同（比如一个走idx_a，一个走idx_b），锁顺序不一致就易形成循环等待 - 显式指定主键值（如
INSERT INTO t(id, name) VALUES (100, 'a')）会绕过自增优化，强制做唯一键扫描，哪怕该id从未存在过
所以，不要把INSERT IGNORE当“无锁插入”用——它只是不报错，不是不加锁。
真正有效的缓解手段，不是删索引，而是收窄锁范围
建更多索引不一定有用，关键是让写操作能“直击要害”。目标只有一个：让InnoDB在插入前，能用**唯一路径**快速定位到目标位置，避免扫描和间隙锁定。
- 给
INSERT SELECT中的WHERE字段建联合索引，高频过滤字段放最左，例如WHERE user_id = ? AND status = ?→ 建INDEX idx_uid_status (user_id, status) - 如果业务允许，把隔离级别降到
READ COMMITTED（需确保binlog_format = ROW），Gap Lock会被禁用，但要注意这会暴露幻读风险 - 批量插入时，务必按主键升序排列数据；乱序插入会让多个线程反复争夺不同页的间隙，冲突概率指数上升
- 慎用
SELECT FOR UPDATE配合后续插入；如果必须用，优先查出主键ID再加锁，而不是直接对非唯一字段加锁
Gap Lock本身不是bug，是RR级别下防止幻读的必要机制。问题往往出在——我们一边用着它，一边又没意识到它锁的到底是什么。
