间隙锁本质是锁定索引记录间的开区间（a,b），不锁实际数据行，仅阻止该空隙插入新记录以防止幻读；它在RR隔离级别、当前读、走索引的范围或特定等值查询下生效，通常作为Next-Key Lock的一部分出现。
MySQL 间隙锁（Gap Lock）不锁任何实际数据行，只锁索引结构中两个相邻值之间的“空档”——也就是索引记录之间的空隙。它的本质是划定一个禁止插入的禁区，确保事务在重复读取同一范围时，不会凭空多出新行（即防止幻读）。
间隙锁锁定的是开区间（a, b）
比如表中 id 索引已有值：10、20、30。
执行 SELECT * FROM t WHERE id BETWEEN 15 AND 25 FOR UPDATE（当前读 + 范围查询），InnoDB 实际会：
- 对 id=20 这条记录加记录锁（Record Lock）
- 同时对 (10, 20) 和 (20, 30) 这两个空隙加间隙锁
注意：(10, 20) 表示所有大于 10 且小于 20 的 id 值，哪怕表里根本不存在 id=15 或 id=17，这个区间也被封锁；其他事务执行 INSERT INTO t VALUES(17, ...) 就会被阻塞。
间隙从哪来？依赖索引排序和实际存在值
间隙不是预设的，而是由当前索引树中已有的记录动态推导出来的：
- 若索引值为 [5, 10]，那么存在的间隙包括：(−∞, 5)、(5, 10)、(10, +∞)
- 若执行 WHERE id > 10 FOR UPDATE，即使表中只有 id=11 这一行，InnoDB 仍会锁住 (10, +∞) —— 因为这是大于 10 的全部可能插入位置
- 若查询 WHERE name = 'alice'，而 name 是普通索引且该值不存在，InnoDB 会找到 name 排序中 'alice' 应处的位置（比如前一个是 'aiden'，后一个是 'bob'），然后锁住 ('aiden', 'bob')
间隙锁生效的前提条件
- 隔离级别必须是 REPEATABLE READ（RR）或 SERIALIZABLE；READ COMMITTED 下不启用间隙锁
- SQL 必须是当前读：即带有 SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE、UPDATE 或 DELETE
- 查询必须走索引（EXPLAIN 显示 type ≠ ALL）；全表扫描不会加间隙锁，但可能升级为表锁
- 常见触发场景：
• 非唯一索引的等值查询（即使只查一行）
• 任意索引的范围查询（>、
• 唯一索引的范围查询（如 id > 100）
• 唯一索引等值查询但记录不存在（如 WHERE id = 999，而最大 id 是 100 → 锁 (100, +∞)）
它其实很少单独出现：Next-Key Lock 是常态
InnoDB 实际加的几乎总是 Next-Key Lock，即记录锁 + 它左边的间隙锁，范围形如 (a, b]（左开右闭）。
例如，id=20 存在，且前一个索引值是 10，后一个是 30：
- InnoDB 会对 id=20 加记录锁，并同时锁住 (10, 20] —— 这就是 Next-Key Lock
- 其中 (10, 20) 是间隙部分，20 是记录部分
纯 Gap Lock 只出现在特殊情形，比如查询条件命中非唯一索引、但对应值完全不存在时，才只锁间隙（如 (10, 20)），不锁任何记录。
