什么是MySQL中的快照隔离级Snapshot Isolation_对比其与RR的区别-mysql教程-PHP中文网

MySQL的REPEATABLE READ不是标准快照隔离，因其Read View在首次快照读时生成而非事务开始时，且不检测写偏斜；幻读“解决”依赖临键锁而非纯快照语义。

什么是mysql中的快照隔离级snapshot isolation_对比其与rr的区别

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 并发执行：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

--- 事务 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，违反约束。