mysql 5.7 rr级别下间隙锁强制启用，所有当前读操作自动使用next-key lock（记录锁+间隙锁），用于彻底解决幻读；唯一索引insert、范围查询、非唯一索引扫描等均会触发，且间隙锁兼容但与插入意向锁互斥，易引发死锁。
MySQL 5.7 默认 RR 隔离级别强制启用间隙锁
MySQL 5.7 的 InnoDB 引擎在 REPEATABLE READ（RR）隔离级别下，**所有当前读操作（如 SELECT ... FOR UPDATE、UPDATE、DELETE）都会自动使用 Next-Key Lock（记录锁 + 间隙锁）**，这是引擎级行为，无需显式声明。只要查询条件涉及索引范围（哪怕没数据）、或唯一键冲突检测，间隙锁就生效。
常见触发场景包括：
-
UPDATE t SET x=1 WHERE id > 100→ 锁住 (100, max_id] 区间 -
SELECT * FROM t WHERE name LIKE 'abc%' FOR UPDATE→ 若name有索引，会锁前缀匹配的整个间隙 -
INSERT INTO t (uid) VALUES (123)→ 若uid是唯一索引，InnoDB 会先加间隙锁防止重复插入，再尝试加记录锁
唯一索引上的 INSERT 也会隐式加间隙锁
很多人误以为只有范围查询才触发间隙锁，但实际在 RR 下，**任何对唯一索引字段的 INSERT 或 INSERT ... ON DUPLICATE KEY UPDATE，都会先申请对应值所在间隙的锁**——这是为了保证唯一性约束不被并发破坏。
例如表有唯一索引 UNIQUE KEY email_idx (email)，两个事务同时执行：
INSERT INTO user (email) VALUES ('a@b.com');
它们会竞争同一个间隙（比如 ('a@b.com', 'b@c.com')），即使该邮箱当前不存在。一旦其中一个事务提交，另一个才能继续；若两者都未提交且互相等待对方释放间隙，就会死锁。
这和主键是否自增无关，只取决于是否走唯一索引路径。
非唯一索引 + 范围条件 = 大范围间隙锁定
当查询没走主键或唯一索引，而是命中普通二级索引（如 created_at），且条件为范围时，InnoDB 会按索引顺序扫描，并对每个扫描到的索引项加 Next-Key Lock。更麻烦的是：**如果该二级索引不是覆盖索引，InnoDB 还要回表查聚簇索引，过程中可能扩大锁范围**。
典型问题语句：
SELECT * FROM order WHERE status = 1 AND created_at > '2026-06-01' FOR UPDATE;
若 status 和 created_at 没联合索引，优化器可能只用 created_at 索引，导致锁住大量无关 status 值的间隙；若 created_at 索引本身稀疏（如只有几个时间点），间隙可能横跨数天甚至数月。
间隙锁不阻塞读，但会卡住写入排队
间隙锁本身是“共享型”的（多个事务可同时持有同一间隙锁），但它在插入时必须升级为记录锁——而这个升级过程是排他的。所以你会看到：
- 多个事务都能成功执行
SELECT ... FOR UPDATE（看似没阻塞） - 但一执行
INSERT或UPDATE，就开始排队、超时、甚至死锁 -
SHOW ENGINE INNODB STATUS中出现lock_mode X locks gap before rec，而非lock_mode X locks rec but not gap
这种“表面畅通、实际卡顿”的现象，正是间隙锁最隐蔽也最容易被忽略的代价：它不直接拦住你，却让后续所有写操作在门口排队等钥匙。
真正难处理的从来不是锁本身，而是那些没走索引的查询、没覆盖的联合索引、以及业务代码里反复出现的“先查再插”逻辑——它们把间隙锁从防御机制变成了并发瓶颈。
