MySQL默认隔离级别REPEATABLE READ通过MVCC+Next-Key Lock避免不可重复读，但仅压制幻读而非消除；READ COMMITTED每次查询新建快照，幻读必然发生；SERIALIZABLE虽真正防止幻读但并发性能极差。
MySQL默认隔离级别是REPEATABLE READ，但不是完全可串行化
MySQL InnoDB 默认事务隔离级别是 REPEATABLE READ，但它和标准 SQL 定义的 RR 有关键区别：InnoDB 通过多版本并发控制（MVCC）+ Next-Key Lock 实现一致性读，避免了“不可重复读”，但**不阻止幻读的语义现象**——只是用间隙锁（Gap Lock）在当前读场景下“压制”了幻行插入。这意味着：
SELECT * FROM t WHERE id = 10;这类快照读不会看到其他事务插入的新行；但
SELECT * FROM t WHERE id = 10 FOR UPDATE;这种当前读会加 Next-Key Lock，阻塞插入，从而“看起来没幻读”。真实并发问题仍可能暴露，尤其在业务依赖“查无结果就插入”的逻辑时。
READ COMMITTED下幻读更明显，但MVCC行为更符合直觉
切换到 READ COMMITTED 后，每次 SELECT 都会生成新快照，所以两次查询可能看到不同数据（解决脏读、不可重复读），但幻读必然发生。典型场景：
BEGIN; SELECT COUNT(*) FROM users WHERE status = 'active'; -- 返回 5 -- 此时事务A插入一条 status='active' 并提交 SELECT COUNT(*) FROM users WHERE status = 'active'; -- 可能返回 6 COMMIT;这个变化在 RC 下合法，在 RR 下被 MVCC “掩盖”，但掩盖不等于消除——如果后续执行
UPDATE ... WHERE status = 'active'，RR 下会更新旧快照里的 5 行，而新插入那行不受影响，业务逻辑可能出错。
Serializable是唯一真正防止幻读的级别，但代价极高
SERIALIZABLE 会让所有普通 SELECT 隐式加上 LOCK IN SHARE MODE，写操作则加排他锁。它确实从机制上杜绝幻读，但副作用显著：
- 并发度急剧下降，大量锁等待
- 容易触发死锁，尤其混合读写频繁的场景
- 应用层若未正确处理
Lock wait timeout exceeded错误，会直接失败
面试常问的“事务中先查后插为何出现重复数据”本质是隔离级别+索引失效
这个问题表面看是幻读，实际往往卡在两个细节：
- WHERE 条件字段**没有索引** → InnoDB 退化为全表扫描，Next-Key Lock 覆盖整个聚簇索引，但锁范围过大反而导致并发插入绕过锁定（例如锁住主键区间，但插入走二级索引路径）
- 使用了
SELECT ... LOCK IN SHARE MODE而非FOR UPDATE→ 共享锁不阻塞其他事务的插入（INSERT 是排他操作，但只和行锁/间隙锁冲突，不和 S 锁直接互斥） - 事务中混用快照读和当前读 → 第一次
SELECT是快照读，第二次加锁却是当前读，中间窗口被插入
SELECT * FROM t WHERE biz_key = 'xxx' FOR UPDATE;
-- 确保 biz_key 有唯一索引
INSERT INTO t (biz_key, ...) VALUES ('xxx', ...); -- 依赖唯一索引报错回滚 
