间隙锁锁定索引记录间的区间（如(10,20)），仅在可重复读隔离级别下启用，用于防止幻读；它不锁记录本身，需配合临键锁才锁边界值，且仅作用于走索引的当前读操作。
MySQL 的间隙锁（Gap Lock）是 InnoDB 在可重复读（RR）隔离级别下为防止幻读而引入的一种锁机制，它锁定的是索引记录之间的“间隙”，而非具体某条记录。理解它的原理和适用场景，对避免死锁、提升并发性能和保证数据一致性至关重要。
间隙锁到底锁什么？
间隙锁锁定的是两个索引值之间的区间，比如索引上有值 10、20、30，那么可能的间隙包括：(-∞, 10)、(10, 20)、(20, 30)、(30, +∞)。它不锁记录本身（那是行锁的事），也不锁边界值——除非配合临键锁（Next-Key Lock，即“间隙锁 + 记录锁”的组合）。
关键点：
- 只在 可重复读（RR） 隔离级别下默认启用；读已提交（RC）下不使用间隙锁（只用行锁），因此可能产生幻读；
- 仅作用于 已存在的索引列，且查询必须走索引（主键或二级索引），全表扫描不会加间隙锁；
- 即使 WHERE 条件没命中任何记录，也可能加间隙锁。例如
SELECT * FROM t WHERE id = 15 FOR UPDATE，而表中只有 10 和 20，InnoDB 仍会锁定 (10, 20) 这个间隙，防止别人插入 15； - 唯一索引的等值查询（且记录存在）通常 不触发间隙锁，因为能精确定位，但范围查询（如
>、BETWEEN）或不存在记录时仍会加。
哪些操作会触发间隙锁？
不是所有 SELECT 或 DML 都会加间隙锁，核心看是否满足“当前读 + 范围/未命中 + 索引扫描”这几个条件：
-
当前读语句：带
FOR UPDATE、LOCK IN SHARE MODE的 SELECT；以及所有的UPDATE、DELETE、INSERT ... ON DUPLICATE KEY UPDATE； -
范围条件扫描：如
WHERE age > 25、WHERE name BETWEEN 'A' AND 'C'，会锁定扫描到的所有间隙； -
唯一索引等值查询但记录不存在：如
SELECT * FROM user WHERE id = 100 FOR UPDATE，而 id=100 不存在，则锁定该值应处的间隙； - 插入意向锁（Insert Intention Lock） 是一种特殊的间隙锁，多个事务想往同一间隙插入不同记录时，各自申请自己的插入意向锁，彼此不冲突——但会与普通间隙锁冲突，这是死锁常见源头。
典型使用场景与实际影响
间隙锁不是“功能”，而是实现 RR 隔离级别的必要代价。它的价值体现在保障业务逻辑正确性上：
- 防幻读：比如转账前检查账户余额是否足够，若不加间隙锁，另一个事务可能插入新流水导致判断失效；
- 唯一性约束维护：在唯一索引上插入前，InnoDB 会对目标位置加间隙锁，防止并发插入相同值（即使还没真正写入）；
- 防止“中间插入”破坏业务规则：例如订单表按创建时间排序分页，若允许在已有记录间随意插入，会导致同一页重复或遗漏；
- 死锁高发区：多个事务以不同顺序访问同一组间隙（如一个锁 (10,20)，另一个先锁 (20,30) 再回锁 (10,20)），极易形成循环等待。
如何规避不必要间隙锁？
间隙锁无法关闭，但可通过设计降低其影响：
- 确认业务是否真需要 RR 隔离级别；若可接受 RC，间隙锁基本消失（代价是可能幻读）；
- 尽量使用 等值查询 + 主键/唯一索引，减少范围扫描；
- 避免在高频并发写入场景下，对非唯一索引字段做范围条件的当前读；
- 插入前先
SELECT ... FOR UPDATE检查时，确保 WHERE 条件能命中索引且尽量缩小范围（如带上主键）； - 监控
SHOW ENGINE INNODB STATUS中的 lock wait 和 gap locks，定位热点间隙。
不复杂但容易忽略：间隙锁的存在让“没查到数据”也未必安全，并发插入和更新常常在这里踩坑。理解它，不是为了消灭它，而是为了让它锁得明白、锁得必要、锁得可控。
