数据库隔离级别发展史

前言

提到数据库隔离级别，就要提到数据库事务的ACID 原则。ACID，即Atomicity, Consistency, Isolation, and Durability 是1983 被 Haerder, T. 和Reuter, A. 第一次在论文 “Principles of transaction-oriented database recovery” 提出，论文详见链接，具体解释如下：

• Atomicity，原子性，简单来说就是事务是一个不可分割的操作，要么全部发生，要么全部不发生。
• Consistency，一致性，事务开始前和结束后，数据的完整性（约束）不会被破坏。这个一致性初次接触可能难以理解，举个经典的例子，把“A 账号余额有100元，B账号余额有0元，A转账给B账号100元”作为一个事务，则事务开始前和结束后，两个账号的余额总和为100元。
• Isolation，隔离性，一个事务不影响其它事务。
• Durability，持久性，事务所所作的数据更改会持久化到数据库中。

其中，对于有些事务是会操作相同的数据集，如果对这部分事务进行完全隔离，则只能够串行化运行事务。在很多系统中，这基本是不能接受的。为了提高事务的处理能力，对事务逐渐定义出了不同的隔离级别，这也就引出了本文的主角——数据库隔离级别。

随着数据库产品数量以及使用场景的膨胀，带来了各种隔离级别选择的混乱，数据库的众多设计者和使用者亟需一个对隔离级别划分的共识，这就是标准出现的意义。而本文就是从标准的发展史为时间线来记录数据库隔离级别的发展史。

一个好的隔离级别定义有如下两个重要的目标：

• 正确：只要实现满足某一隔离级别定义，就一定能获得对应的正确性保证。
• 实现无关：常见的并发控制的实现方式包括，锁、OCC以及多版本 。而一个好的标准不应该限制其实现方式。

ANSI SQL标准(1992)：基于异象

1992年ANSI首先尝试指定统一的隔离级别标准，其定义了不同级别的异象(phenomenas)， 并依据能避免多少异象来划分隔离标准。异象包括：

• 脏读（Dirty Read）: 读到了其他事务还未提交的数据；
• 不可重复读（Non-Repeatable/Fuzzy Read）：由于其他事务的修改或删除，对某数据的两次读取结果不同；
• 幻读（Phantom Read）：由于其他事务的修改，增加或删除，导致Range的结果失效（如where 条件查询）。

通过阻止不同的异象发生，得到了四种不同级别的隔离标准：

ANSI SQL标准看起来是非常直观的划分方式，不想要什么就排除什么，并且做到了实现无关。然而，现实并不像想象美好。因为它并不正确。

A Critique of ANSI(1995)：基于锁

几年后，微软的研究员们在A Critique of ANSI SQL Isolation Levels一文中对ANSI的标准进行了批判，指出其存在两个致命的问题：

1，不完整，缺少对Dirty Write的排除

ANSI SQL标准中所有的隔离级别都没有将Dirty Write这种异象排除在外，所谓Dirty Write指的是两个未提交的事务先后对同一个对象进行了修改。而Dirty Write之所以是一种异象，主要因为他会导致下面的一致性问题：

H0: w1[x] w2[x] w2[y] c2 w1[y] c1

这段历史中，假设有相关性约束x=y，T1尝试将二者都修改为1，T2尝试将二者都修改为2，顺序执行的结果应该是二者都为1或者都为2，但由于Dirty Write的发生，最终结果变为x=2，y=1，不一致。

2，歧义

ANSI SQL的英文表述有歧义。以Phantom为例，如下图历史H3：

H3：r1[P] w2[insert y to P] r2[z] w2[z] c2 r1[z] c1

假设T1根据条件P查询所有的雇员列表，之后T2增加了一个雇员并增加了雇员人数值z，之后T1读取雇员人数z，最终T1的列表中的人数比z少，不一致。但T1并没有在T2修改链表后再使用P中的值，是否就不属于ANSI中对Phantom的定义了呢？这也导致了对ANSI的表述可能有严格和宽松两种解读。对于Read Dirty和Non-Repeatable/Fuzzy Read也有同样的问题。

那么，如何解决上述两个问题呢？Critique of ANSI的答案是：宁可错杀三千，不可放过一个，即给ANSI标准中的异象最严格的定义。Critique of ANSI改造了异象的定义：

P0: w1[x]…w2[x]…(c1 or a1) (Dirty Write)

P1: w1[x]…r2[x]…(c1 or a1) (Dirty Read)

P2: r1[x]…w2[x]…(c1 or a1) (Fuzzy or Non-Repeatable Read)

P3: r1[P]…w2[y in P]…(c1 or a1) (Phantom)

此时定义已经很严格了，直接阻止了对应的读写组合顺序。仔细可以看出，此时得到的其实就是基于锁的定义:

• Read Uncommitted，阻止P0：整个事务阶段对x加长写锁
• Read Commited，阻止P0，P1：短读锁 + 长写锁
• Repeatable Read，阻止P0，P1，P2：长读锁 + 短谓词锁 + 长写锁
• Serializable，阻止P0，P1，P2，P3：长读锁 + 长谓词锁 + 长写锁

问题本质

可以看出，这种方式的隔离性定义保证了正确性，但却产生了依赖实现方式的问题：太过严格的隔离性定义，阻止了Optimize或Multi-version的实现方式中的一些正常的情况：

• 针对P0：Optimize的实现方式可能会让多个事务各自写自己的本地副本，提交的时候只要顺序合适是可以成功的，只在需要的时候才abort，但这种选择被P0阻止；
• 针对P2：只要T1没有在读x，后续没有与x相关的操作，且先于T2提交。在Optimize的实现中是可以接受的，却被P2阻止。

回忆Critique of ANSI中指出的ANSI标准问题，包括Dirty Write和歧义，其实都是由于多Object之间有相互约束关系导致的，如下图所示，图中黑色部分表示的是ANSI中针对某一个异象描述的异常情况，灰色部分由于多Object约束导致的异常部分，但这部分在传统的异象定义方式中并不能描述，因此其只能退而求其次，扩大限制的范围到黄色部分，从而限制了正常的情况。：

由此，可以看出问题的本质：由于异象的描述只针对单个object，缺少描述多object之间的约束关系，导致需要用锁的方式来作出超出必须的限制。相应地，解决问题的关键：要有新的定义异象的模型，使之能精准的描述多object之间的约束关系，从而使得我们能够精准地限制上述灰色部分，而将黄色的部分解放出来。Adya给出的答案是序列化图。

A Generalized Theory(1999)：基于序列化图

Adya在Weak Consistency: A Generalized Theory and Optimistic Implementations for Distributed Transactions中给出了基于序列化图得定义，思路为先定义冲突关系；并以冲突关系为有向边形成序列化图；再以图中的环类型定义不同的异象；最后通过阻止不同的异象来定义隔离级别。

序列化图（Direct Serialization Graph, DSG）

序列化图是用有向图的方式来表示事务相互之间的依赖关系，图中每个节点表示一个事务，有向边表示存在一种依赖关系，事务需要等到所有指向其的事务先行提交，如下图所示历史的合法的提交顺序应该为：T1，T2，T3：

这里的有向边包括三种情况：

• 写写冲突ww（Directly Write-Depends）：表示两个事务先后修改同一个数据库Object(w1[x]…w2[x]…)；
• 先写后读冲突wr（Directly Read-Depends）：一个事务修改某个数据库Object后，另一个对该Object进行读操作（w1[x]…r2[x]…）；
• 先读后写冲突rw（Directly Anti-Depends）：一个事务读取某个Object或者某个Range后，另一个事务进行了修改（r1[x]…w2[x]… or r1[P]…w2[y in P]）；

基于序列化图的异象定义：

根据有向图的定义，我们可以将事务对不同Object的依赖关系表示到一张同一张图中，而所谓异象就是在图中找不到一个正确的序列化顺序，即存在某种环。而这种基于环的定义其实就是将基于Lock定义的异象最小化到图中灰色部分：

1，P0(Dirty Write) 最小化为 G0(Write Cycles)：序列化图中包含两条边都为ww冲突组成的环，如H0：

H0: w1[x] w2[x] w2[y] c2 w1[y] c1

可以看出T1在x上与T2写写冲突，T2又在y上与T1写写冲突，形成了如下图所示的环。

2，P1(Dirty Read) 最小化为 G1：Dirty Read异象的最小集包括三个部分G1a(Aborted Reads)，读到的uncommitted数据最终被abort；G1b(Intermediate Reads) ：读到其他事务中间版本的数据；以及G1c(Circular Information Flow)：DSG中包含ww冲突和wr冲突形成的环。

3，P2(Fuzzy or Non-Repeatable Read) 最小化为 G2-item(Item Anti-dependency Cycles) ：DSG中包含环，且其中至少有一条关于某个object的rw冲突

4，P3(Phantom) 最小化为 G2(Anti-dependency Cycles): DSG中包含环，并且其中至少有一条是rw冲突，仍然以上面的H3为例：

H3：r1[P] w2[insert y to P] r2[z] w2[z] c2 r1[z] c1

T1在谓词P上与T2 rw冲突，反过来T2又在z上与T1wr冲突，如下图所示：

对应的隔离级别：

通过上面的讨论可以看出，通过环的方式我们成功最小化了异象的限制范围，那么排除这些异象就得到了更宽松的，通用的隔离级别定义：

• PL-1（Read Uncommitted）：阻止G0
• PL-2（Read Commited）：阻止G1
• PL-2.99（Repeatable Read）：阻止G1，G2-item
• PL-3（Serializable）：阻止G1，G2

其他隔离级别：

除了上述的隔离级别外，在正确性的频谱中还有着大量空白，也就存在着各种其他隔离级别的空间，商业数据库的实现中有两个比较常见：

1，Cursor Stability

该隔离界别介于Read Committed和Repeatable Read之间，通过对游标加锁而不是对object加读锁的方式避免了Lost Write异象。

2， Snapshot Ioslation

事务开始的时候拿一个Start-Timestamp的snapshot，所有的操作都在这个snapshot上做，当commit的时候拿Commit-Timestamp，检查所有有冲突的值不能再[Start- Timestamp, Commit-Timestamp]被提交，否则abort。长久以来，Snapshot Ioslation一直被认为是Serializable，但其实Snapshot Ioslation下还会出现Write Skew的异象。很多文章都是以黑白球为例来解释Snapshot Ioslation 下的Write Skew异象，如下图：

3，Serializable Snapshot Isolation

可串行化快照隔离(serializable snapshot isolation或SSI)是在快照隔离级别之上，支持串行化。

如果是事务1读x写y，事务2是读y写z会不会有write skew问题呢？不会。下面执行结果是等价于事务2先执行，然后事务1执行的串行顺序的。

r1x r2y w1y w2z c1 c2
r2y w2z c2 r1x w1y c2

仔细想一下，单独的读x写y，读y写x都可以，但两者一起，就出问题了。总结出来，快照隔离存在的write skew的问题，本质上需要至少两个条件：

• 有读写冲突
• 依赖成环
  如果可以破坏这些条件，就可以避免write skew，达到可串行化了。所以要做的就是检测不同事务之间的读写依赖是否形成环。x的值依赖于事务2，而被事务1依赖，y的值依赖于事务1，成环了。学过数据结构我们知道，检测图中存在环我们可以使用深度优先遍历遇到之前走过的结点。但是对性能有一定的影响。可以做一个简化的措施，允许误判以换取性能。

实现是这样子的，为每个值维护一个出边和一个入边。如果某个值即存在出边又存在入边，则可能是存在环的。我们宁可错杀一千，不要放过一个，事务操作中，只要检测到这种情况，就abort掉。还是看上面的例子：

r1x r2y w1y w2x c1 c2

事务2读y，y被事务2依赖，于是在y的值设置出边。执行到w1y时，事务1写y，于是y依赖于事务1，设置y的入边。这时我们发现y的入边出边都设置了，有潜在成环的可能性。于是让abort掉事务1。

这里说的是可串行化快照实现方式之一。还有一些其它的方式也可以实现，本质上都是要对读写冲突进行处理。对于OLTP类型的业务，大部分的流量都是在读操作，而读是不会被abort掉的，所以这类场合，实现可串行化快照隔离引入的性能开销可以接受。

总结

对于事务隔离级别的标准，数据库的前辈们进行了长久的探索：

• ANSI isolation levels定义了异象标准，并根据所排除的异象，定义了，Read Uncommitted、Read Committed、Repeatable Read、Serializable四个隔离级别；
• A Critique of ANSI SQL Isolation Levels认为ANSI的定义并没将有多object约束的异象排除在外，并选择用更严格的基于Lock的定义扩大了每个级别限制的范围；
• Weak Consistency: A Generalized Theory and Optimistic Implementations for Distributed Transactions认为基于Lock的定义过多的扩大了限制的范围，导致正常情况被排除在外，从而限制了Optimize类型并行控制的使用；指出解决该问题的关键是要有模型能准确地描述这种多Object约束；并给出了基于序列化图的定义方式，将每个级别限制的范围最小化。

参考

A History of Transaction Histories
ANSI isolation levels
A Critique of ANSI SQL Isolation Levels
Weak Consistency: A Generalized Theory and Optimistic Implementations for Distributed Transactions
Generalized Isolation Level Definitions