RR级别下范围查询必然触发间隙锁，因其依赖Next-Key Lock机制锁定索引区间（如(10,20)）以防止幻读，无论区间内是否存在数据，只要走索引且为当前读，InnoDB就主动加锁保护空白位置。
因为范围查询在 RR 隔离级别下必须防止幻读，而间隙锁是 InnoDB 实现这一目标的刚性机制——它不看有没有数据，只看索引区间是否可能被插入新行。
RR 下范围查询为什么必然触发间隙锁
范围查询（如 WHERE id > 10 AND id ）天然对应一段索引区间。InnoDB 在 RR 级别下默认使用 <code>next-key lock，即“记录锁 + 间隙锁”的组合。哪怕当前表里 id 只有 1、5、25，执行该查询时，InnoDB 仍会锁定 (10, 20) 这个开区间——不是因为里面有数据，而是因为别人可能往这儿插。
这个行为与是否命中数据无关：查到 15 会锁 (10, 15] 和 (15, 20)；查不到任何记录，照样锁 (10, 20)。核心逻辑是“保护查询语义的稳定性”，而非“保护已有数据”。
- 只在 RR 隔离级别生效；RC 下该查询只加记录锁（如果命中），不加间隙锁
- 必须走索引（主键或二级索引），全表扫描不会加间隙锁
- 锁范围由索引树结构决定，不是 SQL 表面写的 WHERE 范围直接映射
间隙锁实际锁住哪些位置
假设表 t 主键为 id，现有值为 1、3、7、10，执行 UPDATE t SET x=1 WHERE id BETWEEN 4 AND 8 FOR UPDATE：
InnoDB 会定位到索引中 3 和 7 之间的位置，再向右延伸至 10，最终加锁区间为 (3, 7] 和 (7, 10)。这意味着：
-
INSERT INTO t VALUES (4, ...)、(5, ...)、(6, ...)全部被阻塞 -
INSERT INTO t VALUES (8, ...)也被阻塞（因为 (7, 10) 包含 8） - 但
INSERT INTO t VALUES (2, ...)或(11, ...)不受影响
注意：BETWEEN a AND b 是闭区间语义，但间隙锁仍是开区间 (a, b)，边界是否被锁取决于 next-key 锁的右闭特性。
为什么唯一索引的等值查询有时也加间隙锁
很多人误以为“唯一索引 + 等值 = 只加记录锁”，其实不然。关键看记录是否存在：
- 若
SELECT * FROM t WHERE id = 5 FOR UPDATE中id = 5存在 → 只加记录锁 - 若
id = 5不存在 → InnoDB 定位到 (3, 7) 间隙，对 (3, 7) 加 gap lock - 若
id是非唯一索引，即使id = 5存在，也会额外锁前后间隙（如 (3, 5] 和 (5, 7)）
根本原因不是“是不是唯一索引”，而是“查询能否精确定位到单一行且该行真实存在”。只要定位失败或索引不唯一，间隙就成禁区。
如何验证当前查询是否加了间隙锁
最直接方式是用另一个事务尝试在疑似间隙内插入数据，观察是否阻塞：
事务 A：BEGIN; SELECT * FROM t WHERE id > 10 AND id
事务 B：INSERT INTO t VALUES (15, 'x'); → 若卡住，说明 (10, 20) 被间隙锁覆盖
更准的方法是查 INFORMATION_SCHEMA.INNODB_TRX 和 INFORMATION_SCHEMA.INNODB_LOCKS（MySQL 5.7+ 已弃用后者），推荐用 SELECT * FROM performance_schema.data_locks（MySQL 8.0+）：
SELECT LOCK_TRX_ID, LOCK_MODE, LOCK_TYPE, LOCK_DATA FROM performance_schema.data_locks WHERE LOCK_TRX_ID = '事务A的ID';
看到 LOCK_MODE 为 GAP 或 NEXT-KEY，且 LOCK_DATA 显示类似 10, 20，就确认是间隙锁。
真正容易被忽略的是：间隙锁不持久化、不写 binlog、只存在于内存锁管理器中，事务一提交就释放——但它造成的阻塞，可能比行锁更隐蔽、更难排查。
