READ COMMITTED下查不到幻读但会不可重复读，因其每次查询新建ReadView，可立即看到已提交的单行修改，导致同记录两次查询结果不同；但范围查询不维护一致性快照，新插入行可见，MySQL不将其定义为幻读，而是当前读可见性变化。
READ COMMITTED 下为什么查不到幻读但会不可重复读
因为 READ COMMITTED 每次查询都生成新 ReadView，能立刻看到其他事务已提交的修改——所以同一条记录两次 SELECT 可能返回不同值（比如被 UPDATE 后再提交），这就是不可重复读；但它对范围查询（如 SELECT * FROM t WHERE id > 10）不加间隙锁，也不维护“快照中该范围有哪些行”的一致性视图，所以别人插入新行后你再查，确实会多出数据，但 MySQL 官方文档和 InnoDB 实现里**不把这叫幻读**，而是归为“当前读可见性变化”。换句话说：它有幻读现象，但不认为这是隔离级别要解决的“幻读问题”。
- 典型错误现象：
SELECT COUNT(*)第一次是 100 行，别人插入 5 行并COMMIT后，第二次查变成 105 行 - 这不是 bug，是
READ COMMITTED的设计预期——它只保证单行读的一致性，不承诺范围查询结果稳定 - 如果你在事务里反复执行相同条件的
SELECT并依赖行数做逻辑判断（比如分页校验、库存预占），就会踩坑
REPEATABLE READ 怎么做到不不可重复读，却仍可能遇到幻读
REPEATABLE READ 在事务第一次查询时就固化一个 ReadView，后续所有普通 SELECT 都基于这个快照，所以同一条记录反复查结果不变——不可重复读被挡住。但幻读的关键在于“新插入的行是否可见”，而 InnoDB 用的是 **MVCC + 间隙锁（gap lock）组合策略**：普通 SELECT 不加锁，靠快照躲过幻行；但一旦用了 SELECT ... FOR UPDATE 或 UPDATE 这类当前读，InnoDB 就会锁住检索范围的间隙，阻止别人插入符合 WHERE 条件的新行。
- 容易忽略的点：幻读只在“当前读”场景暴露，比如你先
SELECT * FROM t WHERE age > 25（快照读，看不到新插入），紧接着SELECT * FROM t WHERE age > 25 FOR UPDATE（当前读），这时如果别人刚插了一条age=30的记录并提交，你就真会查到它——而且这条记录会被加上锁 -
REPEATABLE READ下幻读不是“完全不存在”，而是“默认被 MVCC 隐藏，但在显式加锁时暴露” - MySQL 8.0+ 中，如果关闭
innodb_locks_unsafe_for_binlog（默认已关），间隙锁行为更严格，反而更容易触发锁等待而非幻读
什么时候必须选 REPEATABLE READ 而不能用 READ COMMITTED
当你的事务需要强一致性语义，且逻辑依赖“多次读取结果绝对不变”时，REPEATABLE READ 是底线。比如订单扣减库存：先查剩余量，再判断是否够扣，最后更新。若中间别人提交了扣减，READ COMMITTED 可能让第二次查库存突然变少，导致超卖。
- 典型场景：金融转账、库存预占、幂等状态机（如“待支付→已支付”状态流转需确认前置状态未变）
- 别被“READ COMMITTED 更快”误导：它减少锁竞争，但代价是业务层要自己处理数据漂移，成本往往更高
- 注意兼容性：某些 ORM（如旧版 Django）默认假设
REPEATABLE READ行为，切到READ COMMITTED可能引发隐式并发异常
如何验证当前事务看到的到底是快照还是当前数据
最直接的办法是结合 SELECT ... FOR UPDATE 和并发插入测试。启动两个会话，都开事务，第一个执行 SELECT * FROM t WHERE id = 1（普通读），第二个插入 id = 1 并提交；再回第一个会话执行 SELECT * FROM t WHERE id = 1 FOR UPDATE——如果返回新数据，说明是当前读；如果查不到，说明还在快照里。
- 查当前隔离级别：
SELECT @@transaction_isolation - 看事务是否已生成
ReadView：SELECT * FROM information_schema.INNODB_TRX中的trx_started时间可辅助判断快照基准点 - 关键提醒：不要依赖
SELECT返回空就断定“没幻行”，得看是不是用了加锁读——很多线上 bug 就卡在这一步误判
真正麻烦的从来不是理论定义，而是你写那行 SELECT 时，根本没意识到它背后是快照读还是当前读，更不知道 WHERE 条件有没有触发间隙锁。这种模糊地带，才是并发问题藏身的地方。
