幻读指同一事务两次查询相同条件时行数不一致，因其他事务插入/删除数据导致结果集变化；不可重复读则指同一行数据内容被修改，二者作用对象不同：前者关注范围集合变动，后者关注单行值变更。
幻读和不可重复读都发生在可重复读级别，但触发条件完全不同
MySQL 默认的 REPEATABLE READ 隔离级别能阻止不可重复读，却仍可能遇到幻读——这不是 MySQL 实现不完善，而是两者作用对象根本不同。
不可重复读只关心「某一行」的内容是否被改过；幻读则关注「满足查询条件的行集合」是否新增或减少。前者是单点变更，后者是范围动态扩张或收缩。
- 不可重复读：你查
id = 100的用户余额，第一次是 500，别人 UPDATE 后提交，你再查变成 300 —— 行存在，值变了 - 幻读：你查
WHERE status = 'pending'有 5 条，别人 INSERT 一条新 pending 记录并提交，你再查变成 6 条 —— 行数变了，且新增的那条你“没见过”
快照读 vs 当前读：同一隔离级别下行为差异的关键
在 REPEATABLE READ 下，普通 SELECT 是快照读（基于 MVCC），它天然规避不可重复读，也对幻读有部分遮蔽；但一旦用到 SELECT ... FOR UPDATE 或 UPDATE ... WHERE 这类当前读，就会激活临键锁（next-key lock），此时幻读才真正暴露出来。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 快照读不加锁，只按事务启动时的
read view过滤版本，所以即使别人插入了新行，只要该行的db_trx_id大于你的视图，就读不到 —— 看似没幻读，其实是“看不见” - 当前读要读最新数据并加锁，InnoDB 会用临键锁锁定查询范围（如
idx_status上的(pending, next_value]），防止别人往间隙插数据；但如果索引缺失、查询走全表扫描，就只能退化为表级锁，性能骤降
INSERT 场景下的幻读最容易被忽略
很多开发者只注意 SELECT 引发的幻读，却在 INSERT 前校验逻辑里栽跟头。典型例子：SELECT COUNT(*) WHERE order_no = 'ORD123' 返回 0，接着执行 INSERT INTO orders ...，结果报 Duplicate entry 'ORD123' —— 因为别人在你 SELECT 和 INSERT 之间插了一条。
- 这个现象不是主键冲突那么简单，本质是你两次操作之间，数据集“凭空多了一行”，而你的事务没对这个“未来可能插入的位置”做任何保护
-
SELECT ... FOR UPDATE在唯一索引上会加“间隙锁 + 记录锁”，能封住order_no = 'ORD123'对应的间隙，但前提是该字段有索引；若没索引，InnoDB 只能锁整个表 - 更稳妥的做法不是靠锁，而是把校验和插入合并为原子操作，比如
INSERT IGNORE或ON DUPLICATE KEY UPDATE，让数据库层兜底
幻读的修复成本远高于不可重复读
不可重复读靠 MVCC 就能干净解决；幻读则必须引入锁机制，而锁直接牵扯到并发吞吐和死锁风险。这也是为什么业务中宁愿接受少量幻读，也不轻易升级到 SERIALIZABLE。
- 临键锁虽能防幻读，但会让原本无冲突的插入操作排队等待，尤其在高写入场景（如订单号自增+状态索引）下，容易形成热点锁
- 如果应用层做了分页查询（
LIMIT 10 OFFSET 20），两次请求之间别人插入数据，第二页可能漏掉或重复某条记录 —— 这种“逻辑幻读”连临键锁都管不了，得靠游标（cursor-based pagination）或时间戳锚点来规避 - 真正需要强一致幻读防护的场景其实很少，比如金融批量扣款、库存预占等；多数 Web 应用用最终一致性+幂等设计更实际
