rr部分解决幻读，靠next-key lock而非mvcc；rc不加间隙锁，必然发生幻读；rr对范围查询加临键锁堵插入，但无法防止删除导致的行数减少。
RR 能解决“部分幻读”，不是靠 MVCC，而是靠 Next-Key Lock；RC 根本不解决幻读，连间隙锁都不加。
RR 用 Next-Key Lock 锁住索引区间，堵死插入
在 RR 隔离级别下，InnoDB 对范围查询（如 SELECT * FROM t WHERE id > 10）默认使用 Next-Key Lock：它 = Record Lock + Gap Lock，锁住一个左开右闭的区间，比如 (10, 20]。这个锁既防止别人改已有记录（Record Lock），也防止别人在 10 和 20 之间插入新行（Gap Lock）。
常见错误现象：开发以为“RR 下 SELECT 不加锁，所以不会阻塞插入”，结果发现 SELECT ... WHERE age BETWEEN 18 AND 25 后，另一个事务插不进 age=22 的记录——就是被间隙锁卡住了。
使用场景：
- 唯一索引等值查询且记录存在 →
Next-Key Lock退化为Record Lock（只锁那行） - 非唯一索引或范围查询 → 一定触发
Next-Key Lock，间隙也被锁 - 没有索引 → 降级为表锁，整个表被堵死
RC 级别下 Gap Lock 被禁用，幻读必然发生
RC 隔离级别会显式禁用 Gap Lock 和 Next-Key Lock，只保留 Record Lock（对已存在记录加锁）和 行级 X/S 锁（用于当前读）。这意味着：
-
SELECT快照读不加任何锁，别人可以随时插入新行 -
UPDATE/DELETE只锁命中的行，不锁间隙 → 插入不受影响 - 两次相同范围查询，第二次可能多出几条刚插入的记录（标准幻读）
参数差异：innodb_locks_unsafe_for_binlog 在旧版 MySQL 中曾控制此行为，但现代版本（5.7+）直接由隔离级别决定：RC 就是不加间隙锁，没商量。
为什么说“只解决部分幻读”？
RR 解决的是「由并发插入导致的幻读」，但对「由并发删除导致的幻读」无能为力——比如事务 A 先查 SELECT * FROM t WHERE status = 1 得到 5 行，事务 B 删除其中 2 行并提交，A 再查就只剩 3 行。这不算 InnoDB 定义的幻读（它特指“凭空多出”的行），而是不可重复读的一种变体（行消失），但业务上同样难受。
容易踩的坑：
- 误以为 RR = 绝对无幻读，结果在业务里遇到“明明没插数据，怎么多了一条？”——其实是自己漏了
FOR UPDATE或没走索引，导致锁失效 - 把 RR 当成银弹，在高并发插入场景下大量间隙锁堆积，引发锁等待甚至死锁
- 切换到 RC 后没重审 SQL 是否加了必要索引，导致原本被间隙锁挡住的插入，现在全变成主键冲突或唯一键冲突
真正难处理的，从来不是“能不能锁住”，而是“该不该锁、锁多宽、谁来承担锁开销”。RR 的临键锁是保守策略，RC 的轻量读是激进策略——选哪个，得看你的查询模式、写入密度、以及能否接受“读到最新但不一致”。
