幻读在READ COMMITTED下确实会发生，因该级别不锁定范围，其他事务插入并提交新行后，当前事务再次查询可能看到新增记录；InnoDB的REPEATABLE READ通过Next-Key Lock可避免多数幻读，但依赖索引且不覆盖所有场景。
幻读在 READ COMMITTED 下确实会发生
READ COMMITTED 隔离级别只保证当前事务中「已提交的读」，但不锁定范围。当另一个事务插入新行并提交后，当前事务再次执行相同 SELECT 时可能看到新增记录——这就是幻读。典型场景如分页查询：SELECT * FROM orders WHERE status = 'pending' LIMIT 10 OFFSET 20，两次执行间若有人插入新 pending 订单，第二页就可能漏掉或重复某条。
- MySQL 默认 InnoDB 的 READ COMMITTED 不加间隙锁（gap lock），仅对命中行加行锁
- PostgreSQL 的 READ COMMITTED 也允许幻读，但实现机制不同：它基于快照，每次查询都取最新已提交快照，所以新插入行只要已提交就会被看到
- 应用层做“查-判-改”逻辑时风险极高，比如先查库存是否充足，再扣减——中间插入新订单可能导致超卖
REPEATABLE READ 能避免多数幻读但有例外
InnoDB 的 REPEATABLE READ 通过间隙锁 + 行锁 + Next-Key Lock 实现，能阻止其他事务在查询范围内插入新行。但这只对「明确范围条件」有效，且依赖索引。如果 WHERE 条件没走索引，InnoDB 会退化为全表扫描+锁全表，性能差且未必真正防住幻读。
- 必须确保查询条件命中索引，否则
SELECT ... WHERE unindexed_column = ?无法使用间隙锁 -
INSERT ... SELECT、UPDATE ... WHERE、DELETE ... WHERE这类语句在 REPEATABLE READ 下也会加 Next-Key Lock，但仅限于被扫描到的索引区间 - MySQL 8.0+ 引入了
READ COMMITTED下的innodb_locks_unsafe_for_binlog=OFF（默认关闭），不影响幻读行为，但影响主从一致性判断
业务代码里不能只靠隔离级别兜底
即使设成 REPEATABLE READ，也无法覆盖所有幻读路径。例如：事务 A 查询用户未读消息数，事务 B 插入一条新消息并提交，A 再次查询仍看不到——这看似“没幻读”，但其实是 A 的快照固化了旧视图；而如果 A 后续执行 SELECT ... FOR UPDATE，InnoDB 会重新加锁并可能触发锁等待或死锁，行为变得不可预测。
一站式AI应用开发和部署工具
- 高一致性要求的场景（如资金流水、库存扣减）建议用
SELECT ... FOR UPDATE显式加锁，而非依赖隔离级别隐式行为 - 分页场景推荐用「游标分页」（
WHERE id > ? ORDER BY id LIMIT N），避免 OFFSET 导致的幻读和性能衰减 - 跨服务调用时，数据库隔离级别完全失效——下游服务自己的事务可能引入新数据，此时需靠分布式锁或幂等设计补位
MySQL 和 PostgreSQL 对幻读的实际处理差异
MySQL InnoDB 在 REPEATABLE READ 下通过 Next-Key Lock 主动阻塞插入，而 PostgreSQL 的 REPEATABLE READ 是快照隔离（SI），它禁止写偏（write skew），但允许幻读——只是 PostgreSQL 文档称其“不会发生幻读”，因为它的定义更窄：只认为「同一查询返回不同数量的行」才算幻读，而它用可串行化快照保证了该数量不变；但如果你在事务中执行两次不同谓词的查询（如先查 status='pending'，再查 status='pending' AND created_at > ?），结果仍可能不一致。
- MySQL 的 REPEATABLE READ ≠ SQL 标准的 REPEATABLE READ，它是增强版，但代价是锁更重、并发更低
- PostgreSQL 想真正防幻读得用
SERIALIZABLE，但它底层是 SSI（Serializable Snapshot Isolation），开销大，还可能因检测到冲突而报错ERROR: could not serialize access due to read/write dependencies - ORM 如 Djan 或 SQLAlchemy 默认不显式设隔离级别，实际生效的是数据库连接池或 driver 的默认值，容易误判
真正难处理的不是“哪个级别能防幻读”，而是业务逻辑是否隐含了「范围不变性」假设——比如“查出所有待处理订单并逐个处理”，这个“所有”在数据库层面根本无法静态定义。
