MySQL的RR隔离级别不能完全避免幻读，因其快照读依赖MVCC不拦新行插入，当前读才触发Next-Key Lock，且该锁需同时满足走索引、范围查询、显式加锁三条件；唯一索引等值查询常只加记录锁不锁间隙，混用快照读与当前读更易引发幻读。
MySQL 的 REPEATABLE READ 隔离级别并不能完全防止幻读，根本原因在于它对“快照读”和“当前读”采用两套不兼容的机制：MVCC 保快照一致性，但不拦新行插入；Next-Key Lock 只在加锁读时生效，且高度依赖索引与查询模式。
快照读能屏蔽新行，但只对 SELECT 有效
事务启动后第一次 SELECT 会生成一个 Read View，后续所有普通 SELECT 都复用它——这意味着你永远看不到其他事务之后插入或更新的行。表面看，两次 SELECT * FROM t WHERE age > 20 返回行数一致，幻读“消失”了。
- 但这个一致性仅限于快照读本身；一旦执行
UPDATE、DELETE或SELECT FOR UPDATE，就切换为当前读，直接访问最新版本数据 - 此时若原快照里没有某行（比如
id = 5），而当前读却能查到并更新它，再查就“突然出现”，形成逻辑断层 - 这种“先查无、再更/删有、再查见”的链路，正是典型幻读场景，且无法靠隔离级别自动拦截
间隙锁（Gap Lock）不是默认开启，必须满足三要素
InnoDB 的 Next-Key Lock（行锁 + 间隙锁）是防幻读的物理手段，但它不会自动生效，必须同时满足：
- 查询走 B+ 树索引（主键、唯一索引、普通二级索引均可；
LIKE '%abc'、函数索引、前缀索引未覆盖完整条件等都不行） - 使用范围条件（如
WHERE id > 100、WHERE name BETWEEN 'a' AND 'z'）；等值查询（WHERE id = 5）通常只锁单行及其前隙，不锁整个区间 - 执行的是当前读语句：
SELECT FOR UPDATE、SELECT LOCK IN SHARE MODE、UPDATE、DELETE
漏掉任意一条，间隙锁就失效。例如：SELECT * FROM t WHERE status = 1 FOR UPDATE 能锁住所有 status=1 的行及间隙；但若 status 字段没索引，InnoDB 退化为全表扫描，只加行锁，不加间隙锁，插入仍自由。
唯一索引等值查询可能不加间隙锁
这是最容易被忽略的例外：当查询条件命中唯一索引（如主键或唯一约束）且为精确等值时，InnoDB 常常只加记录锁（Record Lock），不加间隙锁。
- 例如：
SELECT * FROM user WHERE id = 100 FOR UPDATE—— 若id是主键，InnoDB 通常只锁定 id=100 这一行，不封锁 (99,100) 或 (100,101) 这类间隙 - 此时其他事务仍可在 id=99 和 id=100 之间插入
id=99.5（如果允许）或在 id=100 后插入id=101（若业务逻辑允许空缺） - 尤其在低基数字段（如
status ENUM('pending','done')）上，InnoDB 可能锁整段索引区间，但行为不稳定，不能依赖
真正要堵死幻读，不能只设 REPEATABLE READ，得结合具体 SQL 判断：是否走索引？是否范围查询？是否当前读？三者缺一不可。否则看似隔离级别够高，实际锁不住插入点。
