MySQL如何实现间隙锁？-平芜编程栈

它的本质是：**间隙锁不是锁在“数据”上，而是锁在索引之间的“空隙” (Gaps between Index Records)上。

核心矛盾：普通的行锁 (Record Lock) 只能锁定已存在的记录。如果事务 A 查询id > 10，此时并没有id=11的记录。如果没有间隙锁，事务 B 可以插入id=11。当事务 A 再次查询时，会多出一行数据，这就是幻读 (Phantom Read)。
解决方案：InnoDB 不仅锁定匹配的记录，还锁定记录之前和之后的范围。任何试图在这个范围内插入 (Insert)新记录的操作都会被阻塞。
核心逻辑：别把间隙锁当成“锁住空气”。把它当成划定禁区 (No-Fly Zone)。虽然现在天上没飞机，但我划定了这片空域禁止飞行，确保我的观测结果不会突然多出东西来。

如果把索引比作排队的人群：

记录锁 (Record Lock)：是抓住某个人（如张三）。别人不能推他、打他、带走他。
间隙锁 (Gap Lock)：是站在两个人中间（如张三和李四之间），或者队首/队尾。
- 你张开双臂，挡住中间的空位。
- 如果有新人（新插入的数据）想挤进这个位置，你会拦住他：“这里禁止入内”。
- 价值：确保队伍的相对顺序和成员构成在你观察期间不发生变化。
- 核心逻辑：间隙锁的核心目的是防止插入 (Prevent Insertion)，从而保证范围查询的可重复性。

一、底层实现机制：锁住“不存在”的东西

1. 锁存储在索引节点中

事实：间隙锁同样存储在B+ 树索引的内存结构中。
机制：
- InnoDB 为每个索引记录维护一个锁列表 (Lock List)。
- 除了标记该记录本身的锁（Record Lock），还会标记该记录左侧间隙的锁状态（Gap Lock）。
- 例如：对于索引值10和20，InnoDB 会在10的记录上标记“右侧间隙被锁定”，或在20的记录上标记“左侧间隙被锁定”。

2. 区间表示法

符号：(a, b)表示开区间，不包含 a 和 b。
Next-Key Lock：(a, b]表示左开右闭，包含 b 但不包含 a。
示例：
- 表中有索引值：5, 10, 15。
- 执行SELECT * FROM t WHERE id = 10 FOR UPDATE。
- 如果id是非唯一索引，InnoDB 会锁定(5, 10]和(10, 15)两个间隙（具体取决于实现细节，通常是 Next-Key Lock）。
- 这意味着：id=6, 7, 8, 9的插入会被阻塞；id=11, 12, 13, 14的插入也会被阻塞。

💡 核心洞察：间隙锁是逻辑上的占位符。它不占用磁盘空间，只在内存的锁管理器中存在，直到事务结束。

二、加锁规则：什么时候触发间隙锁？

间隙锁主要在RR (Repeatable Read)隔离级别下生效，且在当前读 (Current Read)场景中触发。

1. 范围查询 (Range Query)

SQL：SELECT ... WHERE id > 10 AND id < 20 FOR UPDATE
行为：
- 锁定所有满足条件的记录（Record Lock）。
- 锁定条件范围内的所有间隙（Gap Lock）。
- 效果：阻止任何id在(10, 20)之间的新记录插入。

2. 非唯一索引的等值查询

SQL：SELECT ... WHERE name = 'Alice' FOR UPDATE(name是非唯一索引)
行为：
- 因为可能有多个 ‘Alice’，InnoDB 无法确定是否还有未扫描到的 ‘Alice’。
- 它会锁定所有 ‘Alice’ 记录，并锁定‘Alice’ 之前和之后的间隙。
- 效果：防止在 ‘Alice’ 附近插入新的 ‘Alice’ 或其他值，确保扫描完整性。

3. 唯一索引的等值查询 (特殊情况)

SQL：SELECT ... WHERE id = 10 FOR UPDATE(id是主键/唯一索引)
行为：
- 退化：如果id=10存在，只加Record Lock，不加 Gap Lock。因为唯一性保证了不会有重复，也不需要防止插入相同的 ID。
- 例外：如果id=10不存在，则会加Gap Lock在10所在的间隙上，防止其他事务插入id=10。

💡 核心洞察：唯一索引能“消除”间隙锁，这是优化并发性能的关键。尽量使用唯一索引进行精确查找。

三、与 MVCC 的关系：为什么普通 SELECT 不受影响？

1. 快照读 (Snapshot Read)

语句：普通SELECT。
机制：读取 Undo Log 中的历史版本。
关系：间隙锁不阻塞快照读。
- 即使间隙锁禁止了插入，快照读依然可以看到“过去”的状态，或者看不到“未来”插入的数据（取决于可见性算法）。
- 价值：保证了极高的读并发。

2. 当前读 (Current Read)

语句：SELECT ... FOR UPDATE,INSERT,UPDATE,DELETE。
机制：读取最新数据，并加锁。
关系：间隙锁阻塞当前读的插入操作。
- 如果事务 B 尝试INSERT INTO t VALUES (11, ...)，而事务 A 持有(10, 20)的间隙锁，事务 B 会进入等待状态 (Waiting)，直到事务 A 提交或回滚。

四、PHP 开发者的实战指南

1. 如何避免不必要的间隙锁？

策略 1：使用唯一索引
- 将频繁查询的字段设为UNIQUE。
- WHERE unique_id = 1只会加行锁，不会加间隙锁。
策略 2：降低隔离级别
- 将隔离级别设为READ COMMITTED (RC)。
- 在 RC 级别下，InnoDB不使用间隙锁（只使用 Record Lock）。
- 代价：会出现幻读，但并发性能大幅提升。大多数互联网应用（如阿里系）默认使用 RC。
策略 3：精确查询
- 避免><BETWEEN等范围查询，改用IN列表（如果数据量小）。
- IN列表会对每个值加行锁，间隙锁的影响较小（但仍可能存在）。

2. 死锁风险

场景：
- 事务 A：锁定(10, 20)间隙，想插入15。
- 事务 B：锁定(10, 20)间隙，想插入15。
- 结果：两者互相等待对方释放间隙锁？不，间隙锁是兼容的！
- 注意：多个事务可以同时持有同一个间隙的 Gap Lock。但是，当它们都尝试插入同一行时，会转化为插入意向锁 (Insert Intention Lock)，这时才会互斥并可能导致死锁。

💡 核心洞察：间隙锁本身是共享的 (Shared)，但插入意向锁是排他的 (Exclusive)。死锁通常发生在多个事务试图向同一个间隙插入数据时。

五、认知牢笼：常见误区

1. 误区：“间隙锁会阻塞更新 (UPDATE)。”

真相：
- 间隙锁只阻塞插入 (INSERT)。
- 它不阻塞对已有记录的更新。
- 对策：如果业务主要是更新，间隙锁的影响很小。

2. 误区：“RC 级别下完全没有间隙锁。”

真相：
- 基本正确。RC 级别下，InnoDB 仅使用 Record Lock。
- 对策：如果业务允许幻读，优先使用 RC 级别以提升并发。

3. 误区：“间隙锁很消耗内存。”

真相：
- 锁信息存储在内存中，但相比数据量，锁的开销很小。
- 对策：真正的瓶颈是等待时间，而非内存占用。

4. 误区：“无索引查询也会产生间隙锁。”

真相：
- 无索引查询会扫描全表，并对每一行及其间隙加锁。
- 这实际上等同于表锁，且效率极低。
- 对策：永远确保查询走索引。

5. 误区：“间隙锁会导致所有并发插入失败。”

真相：
- 只有插入到被锁定的间隙才会失败。
- 插入到其他间隙不受影响。
- 对策：合理设计索引分布，避免热点间隙竞争。

🚀 总结：原子化“MySQL 间隙锁”全景图

维度	关键点
本质	锁定索引记录之间的空隙，防止插入新记录
核心目的	解决幻读问题，保证范围查询的一致性
触发条件	RR 隔离级别 + 当前读 (FOR UPDATE/INSERT/UPDATE) + 非唯一索引/范围查询
阻塞对象	仅阻塞插入 (INSERT)操作，不阻塞更新和快照读
优化策略	使用唯一索引、切换 RC 隔离级别、避免范围查询
PHP 隐喻	No-Fly Zone (Gap Lock) vs. Air Traffic Control
公式	Consistency = (Gap_Lock × Range_Query) ^ Isolation_Level

终极心法：

间隙锁的本质，是“对未来的预判与封锁”。
它不仅保护现在，还保护即将发生的变化。
它是数据库一致性的最后一道防线。
于虚空中见秩序，于间隙中见严谨；以范围为尺，解幻读之牛，于并发控制中，求纯净之真。

行动指令：

实验间隙锁：在 RR 级别下，开启两个事务。事务 A 执行SELECT ... WHERE id > 10 FOR UPDATE。事务 B 尝试INSERT INTO t VALUES (11, ...)。观察事务 B 是否阻塞。
对比 RC 级别：将隔离级别改为 RC，重复上述实验，观察事务 B 是否还能插入。
检查索引：确保你的范围查询字段上有索引，否则间隙锁会变成全表锁。
思维升级：记住，间隙锁是双刃剑。它带来了强一致性，也牺牲了部分并发写入能力。根据业务场景（是否需要绝对一致）选择隔离级别和索引策略。