MySQL的REPEATABLE READ不是标准快照隔离，因其Read View在首次快照读时生成而非事务开始时，且不检测写偏斜；幻读“解决”依赖临键锁而非纯快照语义。
MySQL 本身没有原生的 SNAPSHOT ISOLATION 隔离级别——这是 SQL Server、PostgreSQL（通过 REPEATABLE READ 的实际行为模拟）等系统才明确支持的语义。InnoDB 的 REPEATABLE READ（RR）常被误认为等同于快照隔离，但二者在幻读处理、Read View 生成时机和写偏斜（write skew）场景下有本质差异。
MySQL 的 RR 不是标准快照隔离
标准快照隔离要求：事务 T 在开始时获取一个全局一致的数据库快照，并在整个生命周期中基于该快照读取 + 允许并发写入（只要不冲突），且能检测并中止写偏斜事务。而 MySQL 的 REPEATABLE READ：
- 不提供写偏斜检测机制，
UPDATE或SELECT ... FOR UPDATE会加锁，但普通SELECT（快照读）完全不阻塞其他事务的写 - Read View 并非在
START TRANSACTION时创建，而是在事务内**第一次执行快照读（如普通SELECT）时才生成** - 它依赖 MVCC + 临键锁（Next-Key Lock）来“解决”幻读，但这个“解决”仅针对当前读；快照读本身仍可能因新插入行被过滤掉而看似没幻读，实则是版本不可见，不是真正隔离
RC 和 RR 下 Read View 的生成时机决定可见性边界
关键区别不在“有没有快照”，而在“快照什么时候拍、拍几次”：
-
READ COMMITTED：每次快照读都新建一个Read View，所以能看到其他事务在本次查询前已提交的修改 -
REPEATABLE READ：仅第一次快照读生成Read View，后续所有快照读复用它——因此“冻结”了当时活跃事务列表，之后提交的事务对本事务不可见 - 标准
SNAPSHOT ISOLATION：快照在事务 START 时刻就确定，且所有读（包括后续SELECT）都严格基于该快照，与是否首次读无关
这意味着：如果你在 RR 下先 START TRANSACTION，隔几秒再执行第一个 SELECT，那这个快照里已经漏掉了这期间提交的事务——而标准快照隔离不会这样。
幻读行为暴露根本差异
假设表 t(id PK, name) 初始有 (1,'a'), (2,'b')，事务 A 和 B 并发执行：
--- 事务 A（RR） START TRANSACTION; SELECT * FROM t WHERE id > 0; -- 返回 (1,'a'), (2,'b') -- 此时事务 B 插入 (3,'c') 并 COMMIT SELECT * FROM t WHERE id > 0; -- 仍返回 (1,'a'), (2,'b')
看起来没幻读？但注意：这不是因为 A “隔离了插入”，而是因为 B 的插入发生在 A 的第一个 SELECT 之后，其版本对 A 的 Read View 不可见。如果 B 在 A 第一次 SELECT 前就提交了，A 就会看到 (3,'c')。
- RR 的“防幻读”只对**当前读**（如
SELECT ... FOR UPDATE）靠临键锁硬拦；快照读只是“碰巧”看不到后来的行 - 标准快照隔离下，幻读被定义为“相同谓词条件返回不同行数”，它允许这种现象存在（SQL-92 标准），但会通过写偏斜检测保证逻辑一致性
- MySQL RR 声称“解决幻读”，其实是混合了 MVCC 可见性 + 锁机制的工程妥协，不是纯快照语义
写偏斜（Write Skew）在 RR 下静默发生
这是最易被忽略的点：RR 级别完全不防止写偏斜。例如两个账户余额共 100，规则是“任一账户余额不能低于 10”。事务 A 检查账户 X 余额为 60 → 改 Y 为 40；事务 B 检查 Y 余额为 40 → 改 X 为 30。两者在 RR 下都能成功提交，最终 X=30, Y=40，总和 70，违反约束。
- 标准快照隔离会在提交阶段检测到两个事务读取了重叠数据集且有写冲突，强制回滚其一
- MySQL RR 对这种跨行逻辑约束无感知，也不会加锁或校验，结果是数据不一致
- 你必须靠应用层加
SELECT ... FOR UPDATE或引入额外唯一约束/触发器来兜底
真正需要快照隔离语义的业务（如金融对账、库存预占），不能依赖 MySQL 的 RR 行为——它看起来像，但关键边界处会掉链子。
