简介： 作者：旺德 / 孟勃荣
谈到事务隔离级别，开发同学都能说个八九不离十。脏读、不可重复读、RC、RR… 这些常见术语也大概知道是什么意思。但是做技术，严谨和细致很重要。如果对事务隔离级别的认识，仅仅停留在大概知道的程度，数据库内核研发者可能开发出令用户费解的隔离级别表现，业务研发者可能从数据库中查出与预期不符的结果。
那么如何判断自己是不是对事务隔离级别有了较为深入的理解了呢？开发同学可以问自己这样两个问题：（1）事务隔离级别分为几类？分别能解决什么问题？是否有明确定义？这样的定义是否准确？（2）当前主流数据库（Oracle/MySQL…）的隔离级别表现和实现是怎样的？是否与“官方”定义一致？
如果能清楚明白的回答这两个问题，恭喜，你对事务隔离级别认识已经非常深刻了。如果不能，也没有关系，读完本文你就有答案了。
1. 事务隔离级别
事务隔离级别，主要保障关系数据库 ACID 特性的 I（Isolation），既针对存在冲突的并发事务，提供一定程度的安全保证。ANSI(American National Standards Institute) SQL 92 标准（http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt）首先定义了 3 种并发事务可能导致的不一致异象：
Dirty read: SQL-transaction T1 modifies a row. SQL- transaction T2 then reads that row before T1 performs a COMMIT. If T1 then performs a ROLLBACK, T2 will have read a row that was never committed and that may thus be considered to have never existed.
Non-repeatable read: SQL-transaction T1 reads a row. SQL- transaction T2 then modifies or deletes that row and performs a COMMIT. If T1 then attempts to reread the row, it may receive the modified value or discover that the row has been deleted.
Phantom: SQL-transaction T1 reads the set of rows N that satisfy some . SQL-transaction T2 then executes SQL-statements that generate one or more rows that satisfy the used by SQL-transaction T1. If SQL-transaction T1 then repeats the initial read with the same , it obtains a different collection of rows.
嫌弃以上定义冗长，可以直接看以下形式化描述：
A1 Dirty Read：w1[x] … r2[x] … (a1 and c2 in any order)
A2 Fuzzy Read：r1[x] … w2[x] … c2 … r1[x] … c1
A3 Phantom Read：r1[P] … w2[y in P] … c2 … r1[P] … c1
其中 w1[x] 表示事务 1 写入记录 x，r1 表示事务 1 读取记录 x，c1 表示事务 1 提交，a1 表示事务 1 回滚，r1[P] 表示事务 1 按照谓词 P 的条件读取若干条记录，w1[y in P] 表示事务 1 写入记录 y 满足谓词 P 的条件。
据此，ANSI 定义了四种隔离级别，分别解决以上三种异常：
根据上述几种异常现象定义隔离级别，可谓十分不严谨，Jim Gray 大名鼎鼎的论文 A Critique of ANSI SQL Isolation Levels（后文简称 Critique）就对此做了批判。
不严谨之一 ：禁止了 P1/P2/P3 的事务，即满足了 Serializable 级别。但是在 ANSI 标准中又明确描述 Serializable 级别为“多个并发事务执行的效果与某种串行化执行的效果等价”。显然这两者是矛盾的，禁止 P1/P2/P3 的事务，不一定能满足“等价于某种串行执行”。所以 Critique 将 ANSI 定义的禁止了 P1/P2/P3 的隔离级别称为 Anomaly Serializable。
不严谨之二 ：异常现象定义不准确，如下例并未被 A1 囊括，却仍然出现了 Dirty Read（Txn2 读到 x +y！=100）。同样，A2/A3 也能举出这样的例子，感兴趣的同学可以自己尝试列举，这里不再详述。
究其原因，ANSI 对异象的定义太为严格，如果除去对事务提交、回滚和数据查询范围的要求，仅保留关键的并发事务之间读写操作的顺序，更为宽松且准确的异象定义如下：
P1 Dirty Read: w1[x]…r2[x]…(c1 or a1)
P2 Fuzzy Read: r1[x]…w2[x]…(c1 or a1)
P3 Phantom: r1[P]…w2[y in P]…(c1 or a1)
不严谨之三： 三种异象仅针对 S(ingle) V(alue) 系统，不足以定义 M(ulti)V(ersion) 系统的隔离性。很多商业数据库所实现的 SI，未违反 P1、P2 和 P3，但又可能出现 Constraint violation，不可串行化。除了 P1/P2/P3，还可能出现哪些异常呢？
P4 Lost Update：r1[x]…w2[x]…w1[x]…c1
A5A Read Skew：r1[x]…w2[x]… w2[y]…c2…r1[y] …(c1 or a1)
A5B Write Skew：r1[x]…r2[y]…w1[y]…w2[x]…(c1 and c2 occur)
A5B2 Write Skew2：r1[P]… r2[P]…w1[y in P]…w2[x in P]…(c1 and c2 occur)
对这四种情况，分别举一个例子：
r1[x=50] r2[x=50] w2[x=60] c2 w1[x=70] c1
Lost Update: 事务 1 和事务 2 同时向同一个账户 x 分别充 20 和 10 块，事务 1 后提交，将 70 块写入数据库，事务 2 提交结果 60 块被覆盖。正确的情况下，事务 1 和 2 提交成功，账户里应该有 80 块。
(x+y=100) r1[x=50] w2[x=10] w2[y=90] c2 r1[y=90] c1
Read Skew: x 和 y 账户分别有 50 块钱，加起来共 100 块。事务 1 读 x（50 块）后，事务 2 将 x 账户的 40 块转到 y 账户，事务 2 提交后，事务 1 读 y（90 块）。在事务 1 看来，x+y=140，出现了不一致。
(x+y>=60) r1[x=50] r2[y=50] w1[y=10] c1 w2[x=10] c2
Write Skew：x 和 y 账户分别有 50 块钱，加起来共 100 块。假设存在某种约束，x 和 y 账户的钱加起来不得少于 60 块。事务 1 和事务 2 在自认为不破坏约束的情况下（分别读了 x 账户和 y 账户），再分别从 y 账户和 x 账户取走 40。但事实上，这两个事务完成后，x+y=20，约束条件被破坏。
(count(P)<=4):r1[count(P)=3],r2[count(P)=3],insert1[x in P],insert2[y in P],c1,c2,
Write Skew2：将 Write Skew 的条件改为范围。
2. 隔离级别实现
上一节介绍了 ANSI 定义的 3 种异象，及根据禁止异象的个数而定义的事务隔离级别。因为不存在严格、严谨的“官方”定义，各主流数据库隔离级别的表现也略有不同，一些现象甚至让用户感到困惑。我认为相较于纠结隔离级别的准确定义，认识各数据库隔离级别的表现和实现，在生产环境中正确的使用它们才是更应该关注的事情。本节将以大篇幅具体的例子为切入点，介绍几种主流数据库隔离级别的表现，及内部对应的实现。
2.1 Lock-based 隔离级别实现
在展示 Lock-based 隔离级别实现前，先介绍几个与锁相关的概念：
Item Lock：对访问行加锁，可以防止 dirty/fuzzy read。
Predicate Lock（gap lock）：对 search 的范围加锁，全表扫描直接对整张表加锁，可防止 phantom read。
Short duration：语句结束后释放锁。
Long duration：事务提交或回滚后释放锁。
上述锁操作组合，便可实现不同级别的事务隔离标准，如下表所示。
其中 S lock 代表共享锁，X lock 代表排它锁。
首先所有写操作加 X locks 时，都会选择 Long duration，否则 short duration 锁被释放后，在事务提交前该条更改可能被其它事务写操作覆盖，造成脏写（dirty write）。
其次对于读操作：
Short duration Item S lock 禁止了 P1 发生，读操作如果遇到正在修改的行（写事务加了 X Lock），阻塞在 S Lock，直到写事务提交。
Long duration Item S lock 禁止了 P2 发生，写操作遇到读事务（S Lock），阻塞在 X Lock 上直到读事务提交或回滚。
Long duration Predicate/Table S Lock 禁止了 P3 发生，(范围) 写操作遇到范围读操作 (加 Predicate S Lock)，会被阻塞，直到读事务提交或回滚。
基于锁实现的三种隔离级别分别能禁止的异象如下表所示：
然而当今数据库基于性能等多方面考虑，很少有完全基于锁实现隔离级别的，MVCC+Lock 的方式，可以满足读请求不加锁，是主流的实现方式。
2.2 Oracle 隔离级别的实现
Oracle 仅支持两种隔离级别：Read Committed 与 Serializable。尽管官方这样描述，Oracle 的 Serializable 实际是基于 MVCC+Lock based 的 SI（Snapshot Isolation）隔离级别。
为实现快照读，内部维护了全局变量 SCN（System Commit/Change Number），在事务提交时递增。读请求获取 Snapshot 便是获取当前最新的 SCN。Oracle 实现 MVCC 的方式是将 block 分为两类：（1）Current blocks 为当前最新的页面，与持久化态数据保持一致。（2）Consistent Read blocks，根据 snapshot SCN 生成相应的一致性版本页面。
以下两个具体的例子展示了：不同隔离级别下，读写语句在数据库内部发生了什么。
Oracle 在 read committed 隔离级别下，每条语句都会获取最新的 snapshot，读请求全部是 snapshot 读。写请求在更新行之前，需要加行锁。由于写操作不会因为有其它事务更新了同一行，而停止更新（除非不满足更新的谓词条件了），因此 Lost Update 有可能发生。
Oracle 在 serializable 隔离级别下，事务开始便获取 snapshot。读请求全部是 snapshot 读，而写请求在更新行之前，需要加行锁。写操作在加锁后，首先检查该行，如果发现：最近修改过这行的事务的 SCN 大于本事务的 SCN，说明它已经被修改且无法被本事务看到，会做报错处理，避免了 Lost Update。这种写冲突的实现，显然是 first committer wins。
下表展示了 Oracle 的两种隔离级别，分别能够避免哪些异象：
2.3 MySQL（InnoDB）隔离级别实现
InnoDB 同样以 MVCC+Lock 的方式实现隔离级别。其中普通 select 语句均是 snapshot read。而 delete/update/select for update 等语句是加锁实现的 current read，如下表所示（注：该表为 Pecona 5.6 版本的代码实现）。
InnoDB 的 RC 隔离级别的表现与 Oracle 相似。而相较于 Oracle 的 SI，InnoDB RR 隔离级别依旧不能避免 Lost Update（例如下例）。究其原因，InnoDB 在 RR 隔离级别下，不会在事务提交时判断是否有其它事务修改过该行。这避免了了 SI 更新冲突带来的回滚代价，带来了可能发生 Lost Update 的风险。
由于 update 等操作均是加锁的当前读，因此 Phantom Read 的现象也是存在的（如下表所示）。但是如果将 Txn1 的 update 语句替换为 select 语句，Phantom Read 现象则可以禁止，因为整个事务 select 语句使用的是同一个 snapshot。
Innodb RR 的实现方式虽然并非并未严格排除 Lost Update 和 Repeatable Read，但其充分利用 MVCC 读不加锁的并发能力，同时 current read 避免了 SI 在更新冲突剧增时过多的回滚代价。
InnoDB 还实现了 Lock Based Serializable（详见 2.1），禁止了所有异象。
3.MySQL (X-Engine) 隔离级别实现
X-Engine 隔离级别实现同样采用 MVCC+Lock 的方式，支持 RC 和 SI，表现与 Oracle 的 RC，Serializable 一致。具体实现层面，X-Engine 实现了行级 MVCC，每条记录的 key 都附有一个 Sequence 代表自己的版本。所有的读操作均是快照读（包括加锁读），读请求所需要的 snapshot 也是一个 Sequence。写写冲突处理依靠两阶段锁，并遵循 First committer wins。
按照惯例，以下面两个例子分析，说明我们的实现原理：
与 Oracle 类似，X-Engine SI 隔离级别，可以避免 Lost Update：
4. 总结
前文介绍了多种数据库隔离级别的表现，对比如上表所示。其种 MySQL 比较特殊，如前文所述，其 RR 级别可以禁止部分幻读现象。开发人员在使用数据库时，需要注意：尽管不同数据库隔离级别名称相同，但是表现却可能存在差异。