幻读是指事务中两次相同范围查询结果行数不一致，由其他事务插入/删除导致；在READ UNCOMMITTED、READ COMMITTED下必然发生，REPEATABLE READ在MySQL中通过间隙锁避免但PostgreSQL中仍可能发生，仅SERIALIZABLE能严格防止。
什么是幻读，以及它在哪些隔离级别下会发生
幻读是指事务中两次执行相同的范围查询（比如 SELECT * FROM orders WHERE status = 'pending'），第二次查到了第一次没看到的新插入（或删除）的行。它和不可重复读的区别在于：不可重复读是“同一行被改了”，幻读是“多出了（或少了）行”。
在 SQL 标准定义中：
-
READ UNCOMMITTED和READ COMMITTED都不防止幻读（后者甚至不防止不可重复读） -
REPEATABLE READ在 MySQL（InnoDB）中通过间隙锁（Gap Lock）实际阻止了幻读，但 PostgreSQL 的REPEATABLE READ仍可能有幻读（因为用的是 MVCC 快照，不加间隙锁） - 只有
SERIALIZABLE级别在所有主流数据库中都严格防止幻读，但代价是性能下降、锁冲突上升
MySQL InnoDB 下如何确认幻读已被避免
MySQL 默认是 REPEATABLE READ，但它靠的是“当前读 + 间隙锁”组合，不是纯 MVCC。这意味着：
- 普通
SELECT（快照读）不会加锁，也不阻止其他事务插入新行 → 可能看到幻影行 - 但带锁的读（如
SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE）会锁住索引范围（含间隙），从而阻止其他事务在该范围内插入
所以关键点是：
- 幻读是否发生，取决于你用的是快照读还是当前读
- 如果业务逻辑依赖“两次查询结果一致”，不能只靠隔离级别，必须显式加锁或改用
SERIALIZABLE - 检查执行计划时注意
EXPLAIN输出是否有Using where; Using index condition，这说明用了索引范围扫描，间隙锁才生效；全表扫描则间隙锁无效
PostgreSQL 中幻读的真实表现与应对方式
PostgreSQL 的 REPEATABLE READ 实际行为更接近 SQL 标准定义：它提供事务开始时刻的全局快照，因此：
- 同一事务内多次
SELECT总是看到相同数据集 → 表面上没有幻读 - 但如果你执行
INSERT或UPDATE基于前一次SELECT的结果（例如“如果没查到就插入”），可能因并发插入导致违反业务约束（如唯一键冲突或逻辑重复）
常见踩坑场景：
- 应用层做“检查后插入”（check-then-insert），没加
SELECT ... FOR UPDATE→ 触发唯一约束错误或脏状态 - 使用
INSERT ... ON CONFLICT DO NOTHING可规避部分问题，但无法替代逻辑一致性校验 - 真正需要强一致性时，必须升到
SERIALIZABLE，PostgreSQL 的可序列化实现是乐观并发控制（OCC），失败时抛出serialization_failure错误，需重试
什么时候该用 SERIALIZABLE 而不是依赖锁或 MVCC
SERIALIZABLE 不是银弹，但它明确划清了“一致性边界”。适用情形包括：
- 财务类操作，如“账户余额不能为负”，且涉及多行校验（例如扣款前检查总待付金额）
- 分布式任务调度中的“选一个未处理任务”，要求严格无重复领取
- 统计报表生成期间禁止任何写入干扰，且不能接受应用层重试逻辑
要注意：
- MySQL 的
SERIALIZABLE会让所有普通SELECT自动转成SELECT ... LOCK IN SHARE MODE，容易阻塞写操作 - PostgreSQL 的
SERIALIZABLE不加锁，但会在提交时验证冲突，失败概率随并发度上升，必须做好重试封装 - 即使设为
SERIALIZABLE，如果查询没走索引，依然可能因锁粒度太大引发严重争用
真正难处理的，从来不是“怎么设隔离级别”，而是“哪条语句该加锁、加什么锁、锁多久”。多数幻读问题，最后都得回到具体 SQL 的执行路径和索引设计上。
