MySQL在RR隔离级别下，间隙锁是防止幻读的强制机制，非可选功能；RC级别下完全不触发间隙锁，仅加记录锁。
MySQL在RR隔离级别下，间隙锁不是“可选功能”，而是防止幻读的强制机制；不理解它，就无法解释为什么SELECT ... FOR UPDATE会阻塞看似无关的INSERT。
间隙锁只在RR隔离级别生效，RC下完全不触发
这是最常被忽略的前提。MySQL默认是REPEATABLE READ，但很多业务显式设为READ COMMITTED（比如Spring Boot应用配置transaction-isolation=READ-COMMITTED），此时WHERE c = 3 FOR UPDATE只会加记录锁，不会锁(1,3)或(3,5)这类间隙。
- RR下：
SELECT * FROM t WHERE id > 2 AND id → 锁住间隙<code>(2,6)，同时可能对命中记录加临键锁 - RC下：同一条语句只锁实际查到的
id=3、id=4、id=5三行，INSERT INTO t VALUES (2.5)能成功 - 验证方式：执行
SELECT * FROM performance_schema.data_locks，RC下看不到LOCK_MODE = 'GAP'的行
间隙锁锁定的是“值之间的空间”，不是记录本身
间隙锁的区间是左开右开的，比如现有主键值1, 3, 5，那么间隙就是(−∞,1)、(1,3)、(3,5)、(5,+∞)。它不关心这个间隙里有没有数据，只阻止其他事务往里面插新值。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
SELECT * FROM t WHERE id = 2 FOR UPDATE→id=2不存在，InnoDB加的是间隙锁(1,3)，不是记录锁 - 此时
INSERT INTO t VALUES (2)会被阻塞，但INSERT INTO t VALUES (1)或INSERT INTO t VALUES (3)不会（它们不落在(1,3)内） - 注意：
UPDATE t SET id = 2 WHERE id = 1仍可执行——间隙锁不阻止对已有记录的更新，只防插入
唯一索引和非唯一索引的间隙锁行为完全不同
是否唯一，直接决定间隙锁的覆盖范围。唯一索引（包括主键）等值查询时，若记录存在，走临键锁；若不存在，只锁单个间隙。而非唯一索引即使等值查询，也会锁“所有可能匹配的间隙”。
- 主键等值查
id = 4（存在）→ 加临键锁(3,4]，即锁记录+前隙 - 主键等值查
id = 4（不存在）→ 只加间隙锁(3,5) - 非唯一索引字段
c = 3→ 即使只有一行满足，也会锁(−∞, min_c)、(min_c, next_c)、(next_c, +∞)中所有涉及的间隙，范围更大、更难预测 - 实操建议：线上高频查询尽量走唯一索引，避免非唯一索引引发意外的大范围间隙锁
间隙锁本身不冲突，但和插入意向锁一起会死锁
间隙锁是共享的（多个事务可以同时持有同一间隙的间隙锁），但它和插入意向锁（Insert Intention Lock）互斥。而插入意向锁又是每个INSERT语句执行前自动申请的，这就构成了死锁温床。
- 事务A：
SELECT * FROM t WHERE id BETWEEN 10 AND 20 FOR UPDATE→ 锁(10,20) - 事务B：
SELECT * FROM t WHERE id BETWEEN 15 AND 25 FOR UPDATE→ 锁(15,25) - 此时两者都持有对方要申请的插入意向锁范围，再各自执行
INSERT INTO t VALUES (18)→ 直接死锁 - 排查方法：
SHOW ENGINE INNODB STATUS里找*** DEATH LOCK ***段，重点关注WAITING FOR THIS LOCK TO BE GRANTED:和HOLDS THE LOCK(S):两部分
真正难的不是记住“间隙锁防幻读”，而是当一条INSERT卡住时，你能快速判断它被哪个间隙锁拦住、那个间隙锁又由哪条上游查询引入——这需要结合performance_schema.data_locks和实际索引结构反向推导，而不是靠背概念。
