MySQL在RR隔离级别下当前读会引发Next-Key Lock，是为了堵住幻读漏洞；其触发需同时满足：InnoDB引擎、RR隔离级别、语句为当前读（如UPDATE/SELECT FOR UPDATE等）。
MySQL在RR隔离级别下当前读会引发Next-Key Lock，不是因为“要锁得更严”，而是InnoDB必须用它堵住幻读漏洞——只要不加这个锁，INSERT就可能在你刚查完的间隙里插进来。
当前读触发Next-Key Lock的三个硬性前提
Next-Key Lock不会凭空出现，它只在同时满足以下三点时才被激活：
- InnoDB引擎（MyISAM不支持）
- 事务隔离级别是
REPEATABLE READ（RC下只加Record Lock，不加Gap Lock） - 语句属于“当前读”：包括
SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE、UPDATE、DELETE
缺一不可。比如你在RR下执行普通SELECT，走的是快照读，根本不会加任何锁；换成SELECT ... FOR UPDATE，立刻切换到当前读路径，Next-Key Lock就生效了。
为什么范围查询一定会锁间隙，哪怕表里没数据
间隙锁（Gap Lock）锁定的是索引值之间的“空白位置”，和有没有实际记录无关。它的存在意义只有一个：防止其他事务往这个区间插入新行。
例如表t(id INT, name VARCHAR(10))，有主键索引，当前只有两行：(1, 'a')、(5, 'b')。执行：
SELECT * FROM t WHERE id > 2 AND id < 4 FOR UPDATE;
结果集为空，但InnoDB仍会加Next-Key Lock，锁定区间(1, 5)——也就是(1, 5]中的间隙部分。因为别人随时可能INSERT INTO t VALUES (3, 'c')，而这条语句在你事务未提交前必须被阻塞。
常见错误现象：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 明明WHERE条件没命中任何行，UPDATE却卡住，等另一个事务释放锁
- 业务日志显示“死锁检测失败”，但SQL看起来只是单行更新
- 压测时并发插入变慢，甚至超时，而INSERT本身没索引问题
非唯一索引让Next-Key Lock覆盖更大范围
主键或唯一索引上的等值查询（如WHERE id = 100）只加Record Lock；但只要WHERE字段是非唯一索引（比如status列有普通索引），哪怕写成WHERE status = 1，InnoDB也会按Next-Key Lock处理。
原因在于：非唯一索引允许重复值，InnoDB无法确定“status=1”对应几行，必须封锁该值对应的所有可能位置——即从上一个不同值到下一个不同值之间的整个区间。
示例：
- 索引
idx_status(status)中，现有status值为0, 1, 1, 1, 2 -
UPDATE t SET c = 1 WHERE status = 1会锁住(0, 2]这个区间，不只是三行记录本身 - 如果
status列没有索引，Server层全表扫描，每条聚簇索引记录都加Next-Key Lock，效果接近表级阻塞
快照读和当前读混用是幻读高发区
同一个事务里，先执行普通SELECT（快照读），再执行SELECT ... FOR UPDATE（当前读），两次结果集很可能不一致——这就是典型的幻读，且完全合法。
比如：
SELECT * FROM coupon WHERE user_id = 123; -- 返回0行（快照读，基于ReadView）<br>INSERT INTO coupon (user_id, code) VALUES (123, 'ABC'); -- 其他事务插入并提交<br>SELECT * FROM coupon WHERE user_id = 123 FOR UPDATE; -- 返回1行（当前读，看到最新数据+加锁）
这不是Bug，是设计使然。MVCC负责快照一致性，Next-Key Lock负责当前读下的防幻读，二者职责分离。一旦混用，幻读必然暴露。
最容易被忽略的一点：UPDATE语句内部其实包含一次隐式当前读。即使你没写SELECT ... FOR UPDATE，只要UPDATE的WHERE能走索引且满足RR+当前读条件，它就会自己加Next-Key Lock——很多死锁就藏在这里，连SQL里都没出现FOR UPDATE字样。
