mysql repeatable read 并非单靠隔离级别数字就防幻读，必须满足“有索引+当前读+间隙锁”三要素：快照读靠mvcc屏蔽新行，当前读才触发next-key lock封锁插入区间；无索引或仅快照读时幻读仍会发生。
REPEATABLE READ 隔离级别本身不能单独解决幻读，必须配合索引和当前读（如 SELECT ... FOR UPDATE）才能真正起效。直接设成 REPEATABLE READ 后不加锁、不走索引，幻读照常发生。
为什么 REPEATABLE READ 看似“防幻读”但实际靠不住
- 普通
SELECT是快照读，靠 MVCC 生成的Read View确保看到事务启动时已提交的数据——这能屏蔽新插入行，仅对快照读有效； - 一旦执行
UPDATE、DELETE或带FOR UPDATE的SELECT，就切换为当前读，会看到其他事务已提交的新行； - 此时若无索引，InnoDB 无法加间隙锁（
Gap Lock），也就锁不住插入点，幻读立刻出现。
常见错误现象：
- 表有主键但查询条件没走索引（例如对
TEXT字段做LIKE '%abc'） -
WHERE条件字段没建索引，导致全表扫描，间隙锁失效 - 用
SELECT ... FOR UPDATE但条件是常量或空范围（如WHERE id = -1），InnoDB 可能不加任何间隙锁
怎么让间隙锁真正生效
确保以下三点同时满足，REPEATABLE READ 下的间隙锁（含临键锁 Next-Key Lock）才会封锁插入区间：
- 查询必须走B+ 树索引（主键、唯一索引、普通二级索引均可，但不能是函数索引或前缀索引未覆盖完整条件）
- 使用范围条件（如
WHERE id > 100、WHERE name BETWEEN 'a' AND 'z'），等值查询只锁单条记录及其前隙，范围查询才锁整个区间 - 执行当前读语句：
SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE、UPDATE、DELETE
示例：
-- 假设表 t 有索引 idx_status ON (status) START TRANSACTION; SELECT * FROM t WHERE status = 1 FOR UPDATE; -- ✅ 锁住所有 status=1 的行 + 它们之间的间隙 INSERT INTO t (status, ...) VALUES (1, ...); -- ❌ 被阻塞（若插入位置落在间隙内） COMMIT;
注意：如果 status 是枚举或低基数字段，InnoDB 可能退化为锁整段索引区间，影响并发；此时应评估是否真需强一致性，或改用应用层校验。
容易被忽略的坑：唯一约束比锁更可靠
很多场景下，开发者执着于“怎么锁得更严”，却忘了最简单的防线：
- 幻读常发生在“先查后插”逻辑中（如判断用户不存在再注册）；
- 即使加了
SELECT ... FOR UPDATE，若并发高、事务长，仍可能因锁等待超时或死锁失败； - 更稳的方式是：直接
INSERT ... ON DUPLICATE KEY UPDATE或依赖唯一索引报错。
比如：
-- user表有 UNIQUE KEY uk_email(email)
INSERT INTO user (email, name) VALUES ('a@b.com', 'Alice')
ON DUPLICATE KEY UPDATE name = VALUES(name);
这样既避免幻读引发的重复插入，又不依赖事务串行化，性能和可靠性都更高。
关键不在隔离级别数字本身，而在于你是否让 InnoDB 知道“该锁哪一段”。没索引的 REPEATABLE READ 和 READ COMMITTED 在幻读防护上没区别；有索引+当前读+间隙锁，才是 MySQL 实际防幻读的铁三角。
