达梦8技术支持笔记（6）

隔离级别和并发控制

SQL92标准定义了四种隔离级别——Read Uncommitted，Read Committed，Repeatable Read和Serializable。定义这4种隔离级别时，制定者主要围绕着基于锁的并发控制来说的。但是后来出现了MVCC，之后主流数据库都开始支持MVCC。有的数据库采用比较纯粹的MVCC实现，比如PostgreSQL；有的则是混杂的，比如MySQL InnoDB。这就会造成数据库的实现和标准的描述有很多出入。

其实我们并不在意标准怎么说。标准只是一个参考，引导我们理解我们能够接触的实际数据库系统的工作原理。我们先从最简单情况谈起。

最不严格的隔离级别

理论上，最不严格的隔离级别应该是不隔离。

不隔离很容易理解，不同的事务可以对同一数据并发的随便改：A事务改了一半的结果B能看到；B改了一半的结果A也能看到；如果A和B反复修改同一个数据，那么彼此的修改可以覆盖。数据系统在没有做隔离防护时，就一定会是这个样子。这样也就无所谓事务了。

这里数据访问冲突可以分为两种：

• Dirty Read，脏读。即一个事务的没提交之前的修改被另外一个事务可以看到。
• Dirty Write，脏写。即一个事务的没提交之前的修改可以被另外一个事务的修改覆盖掉。

其实脏读在某些场景下还是可以接受的，比如完全不需要“读取-计算-修改”逻辑的事务。这种事务完全不在意别的事物是怎么修改的，就是自己改自己的；要不就是业务上“就算是基于一个错误的前提进行了数据修改，结果也可以接受”的场景。

而脏写是无法被接受的，因为他会让事务原子性无法实现。试想以下A和B两个事务的行为（假设x的值一开始是0）：

事务A	事务B
set x = 1
	set x = 2
get x （得到2）
	rollback
commit

事务B将事务A的修改覆盖了，将x改为2，然后回滚。但是事务A却commit了。此时x应该是多少呢？从事务A的角度可能应该是1，但是从事务B的角度应该是0。这种情况无论如何都不能自洽。因此，任何支持事务的数据库都有一个基本原则：不论隔离级别是什么，脏写都是不允许的！！

如何避免脏写呢？答案很简单——使用锁。实际上，一般数据库都会使用排他锁来标记要修改的数据（update，delete，select … for update)。锁的存在可以保证——写要block写。这个规则永远生效。

在MySQL InnoDB中，这种锁被称为“X锁”。它的特性是，只要有一个事务获取了一条数据的X锁，其他事物如果也想获取这个锁，就必须等待，直到第一个事务提交/回滚后释放锁，或者等到超时自动回滚。例如上面的例子的第二行事务B尝试进行set x = 2就会被排他锁卡住。有很多教程会提示一些数据库的某些隔离级别是使用MVCC而不是锁的方案来实现的，说的好像用了MVCC就完全不需要锁。这是非常容易引起误解的。事务数据库对于写操作永远需要锁来避免脏写，即使是基于MVCC的数据库。所谓某个隔离级别使用MVCC不需要锁，仅仅是指在读取的时候是否需要锁。

所以，最不严格的隔离级别的隔离级别是允许脏读，但不允许脏写。这种隔离级别被称为Read Uncommitted。这种隔离级别一般不建议使用。事务应该是数据被修改的最小单位，而Read Uncommitted丧失了“事务”这个词本身存在的意义。虽然该隔离级别可以带来一些性能上的优势，但因为其容易造成数据由于并发操作带来的问题，所以应该用在不不太在意数据正确性的场景。但如果你的业务需要性能上的优势，就说明请求量很高，而请求量很高的业务一般很重要，不太可能不需要数据正确性。如果访问请求量不高，直接用默认的隔离级别（有的数据库是Read Committed，有的是Repeatable Read）就是了，没有必要去折腾数据库配置。

如果是高性能的简单数据操作（比如根据数据ID直接修改数据行），用Read Uncommitted是可行的。但既然这样，为什么不用一个正儿八经的NoSQL数据库（比如RocksDB），从而得到高的多写入性能？

Read Uncommitted在SQL92里被定义为最低级别的隔离。但在PostgreSQL中，Read Uncommitted压根就没有实现，设置Read Uncommitted等价于设置Read Committed。

简单来说，对于事务性数据库，Read Uncommitted是鸡肋一般的存在。诸位可以无视之。

Read Committed和Repeatable Read

把这俩种隔离级别放一起说是因为它们的基本原则是一样的：读不block读和写，写不block读。只不过是发生了并行读写的隔离效果不太一样。此外，它们两个对OLTP业务代码的编写的影响差不多——它们都无法解决“写前提困境“。在深入讨论之前，这里先复述一遍这俩隔离级别的意思。

Read Committed是指一个事务能看到另外一个事务对一条数据记录已经提交的修改。例如下面的操作序列（假设变量x的值一开始是0）：

事务A	事务B
get x (得到0)
	set x = 1
	commit
get x (得到1)
commit

这里可以看到事务A对x的两次读取，因为发生在事务B对x修改的前后，得到了不同的结果。事务A可以看到事务B已经提交的修改。

Repeatable Read是指一个事务一旦开始，反复读取一条数据记录，都会得到相同的结果。或者说，假如有两个事务A和B，A在B之前开始，那么B对数据的修改对于事务A总是不可见的。例如下面的操作序列（假设变量x的值一开始是0）：

事务A	事务B
get x (得到0)
	set x = 1
	commit
get x (得到0)
commit

Repeatable Read的直观感觉仿佛是给事务做一个整个数据库做了一个快照，所以很多时候这种隔离级别又被称为Snapshot Isolation。"快照"的功能在一些场景下非常重要，如：

• 数据备份。例如数据库S从数据库M中复制数据，但是同时M数据库又被持续修改。S需要拿到一个M的数据快照，但是又不能真的把M给停了。
• 数据合法性检查。例如有两张数据表，一张记录了当时的交易总额，另外一张表记录了每个交易的金额。那么在读取数据时，如果没有快照的存在，交易金额的总和可能与当时的交易总额对不上，因为随着检查事务的进行，新的交易记录数据会被提交。这些新的提交会被检查事务看到。

在基于MVCC的数据库中，一般认为只实现了Read Committed和Repeatable Read两隔离级别。PostgreSQL在9.1以前，Serializable和Repeatable Read是一样的（PostgreSQL 9.1以后的Serializable增强了数据依赖性的检查）。

此外值得一提的是幻读的问题。在SQL92标准中提到了Repeatable Read中是可以出现幻读的——即一个事务尽管不能读取到后续其他事务对现有数据的修改，但是能够读取到插入的新数据。但是，基于MVCC的实现，Repeatable Read可以完全避免幻读（这岂不是更好）。无论MySQL还是PostgreSQL在Repeatable Read隔离级别都不会出现幻读。

MVCC

MVCC是"Multi-Version Concurrency Control"的缩写。名字看上去很吓唬人，有点不明觉厉，但是可以这样简单理解——对数据库的任何修改的提交都不会直接覆盖之前的数据，而是产生一个新的版本与老版本共存，使得读取时可以完全不加锁。这个版本一般用进行数据操作的事务ID(单调递增）来定义。MVCC大致可以这么实现：

每个数据记录携带两个额外的数据created_by_txn_id和deleted_by_txn_id。

• 当一个数据被insert时，created_by_txn_id记录下插入该数据的事务ID，deleted_by_txn_id留空。
• 当一个数据被delete时，该数据的deleted_by_txn_id记录执行该删除的事务ID。
• 当一个数据被update时，原有数据的deleted_by_txn_id记录执行该更新的事务ID，并且新增一条新的数据记录，其created_by_txn_id记录下更新该数据的事务ID

在另一个事务进行读取时，由隔离级别来控制到底取哪个版本。同时，在读取过程中，完全不加锁（除非用SELECT … FOR UPDATE强行加锁）。这样可以极大降低数据读取时因为冲突被Block的机会。

那么那些多出来的无用数据怎么被最终被清理呢？支持MVCC的数据库一般会有一个背景任务来定时清理那些肯定没用的数据。只要一个数据记录的deleted_by_txn_id不为空，并且比当前还没结束的事务ID中最小的一个还要小，该数据记录就可以被清理掉。在PostgreSQL中，这个背景任务叫做“VACUUM”进程；而在MySQL InnoDB中，叫做“purge“。

在PostgreSQL的实现中，MVCC产生的所有版本的节点都生成存储数据表的B+树的节点。新的节点和老的节点并存，只是上边的标记不同。这个实现的好处是选择读取哪个版本非常方便，可以和B+树的搜索算法合并到一起，还能兼顾SSI检测（下文会提到）。坏处是清理废弃数据相对麻烦。

MySQL采用Undo Log的实现。这种实现下，用于存储数据表的B+树节点总是只保留最新的数据，而老版本的数据被放在Undo Log里，并且以指针的形式关联起来，形成一个链表。这样，在查找老的版本时，需要按链表顺序查找，直到找到created_by_txn_id <= 当前事务ID的最新那条记录即可。这种实现的优缺点和PostgreSQL正相反，查询时会在B+树查找后多引入一个链表查询；但是清理废弃数据时会更简单，只要把Undo Log找到一个合适的位置一刀切了即可。

有了MVCC，Read Committed和Repeatable Read就的实现就很直观了：

• 对于Read Committed，每次读取时，总是取最新的，被提交的那个版本的数据记录。
• 对于Repeatable Read，每次读取时，总是取created_by_txn_id小于等于当前事务ID的那些数据记录。在这个范围内，如果某一数据多个版本都存在，则取最新的。

有趣的是，隔离级别可以是一个Session级别的配置。即每一个Session可以在运行时选择自己希望使用什么隔离级别，也可以随时修改（只要当前没有尚未结束的事务）。每个Session的隔离级别和其他Session是什么隔离级别完全无关。Session只要根据自己的隔离级别，选择用MVCC提供的合适的版本即可。

MySQL InnoDB、PostgreSQL、Oracle （从版本4开始）、MS SQL Server（从版本2005开始）都实现了MVCC。值得一提的是MySQL InnoDB尽管一开始就实现了MVCC，但是之前很多人还在使用MyISAM存储引擎，而MyISAM根本就不支持事务，更不要提MVCC。直到MySQL 5.5.5，InnoDB才成为MySQL默认的搜索引擎。因此如果有想用MySQL做隔离级别实验的读者最好先弄清自己用的MySQL版本和存储引擎。

写前提困境

尽管在MVCC的加持下Read Committed和Repeatable Read都可以得到很好的实现。但是对于某些业务代码来讲，在当前事务中看到/看不到其他的事务已经提交的修改的意义不是很大。这种业务代码一般是这样的：

1. 先读取一段现有的数据
2. 在这个数据的基础上做逻辑判断或者计算；
3. 将计算的结果写回数据库。

这样第三步的写入就会依赖第一步的读取。但是在1和3之间，不管业务代码离得有多近，都无法避免其他事务的并发修改。换句话说，步骤1的数据正确是步骤3能够在业务上正确的前提。

在Repeatable Read下是解决不了这个问题的，因为在步骤3时，当前事务根本就无法看到另外一个事务对数据的修改。这个问题一般被称为Lost Updates。看这个例子，假设用Repeatable Read隔离级别实现一个计数器：

事务A	事务B
get counter (counter = 1)
	get counter (counter = 1)
	counter = counter + 1 (counter = 2)
	set counter = 2
	commit
counter = counter + 1 (counter = 2)
set counter = 2
commit

这时，事务A结束后，就会丢掉一次counter的计数。

而Read Commited尽管能够看到其他事务已经提交的修改，问题在于，在Read Commited，你必须重复写一句select语句才能拿到。而不管你反复读取多少次，不管这个select离得与下面的update有多近，理论上都无法避免丢失其他事务的修改。

简单来说，这个问题就是在修改的事务在提交时，无法确保这个修改的前提是否还可靠。这种问题我称之为写前提困境。

解决这类问题有3种办法：

• 数据库支持某种代码块，这个代码块的执行是排他的；
• 加悲观锁，把期望依赖的数据独占，在修改完成前不允许其他并发修改发生；
• 加乐观锁，在事务提交的一刹那（注意是commit时，不是修改时），检查修改的依赖是不是没有被修改；

在事务性数据库中，第一种被称为Actual Serial Execution，第二种是加锁（手工或者自动）；第三种被称为Serializable Snapshot Isolation, SSI。

Actual Serial Execution

Actual Serial Execution是一种执行的效果，即一段代码在数据库服务器端执行时不会受到其他并发控制的干扰。但要达成这个效果并不简单。

最简单的实现方案是让整个数据库只能单线程跑。这样什么并发隔离保护的机制都可以不要，所有的数据不会有任何并发修改的问题。一些NoSQL的存储，如Redis、VoltDB都是这么实现的。但是他们这么实现是有原因的，因为他们都是基于内存的存储，其数据操作的延迟相对于网络IO几乎可以忽略不计。所以即使是单线程，配合nonblocking IO，他们的并发性能也可以非常高。但这个假设对事务性数据库并不成立，因为事务性数据库要操作磁盘/SSD。即便是SSD的写入速度，也会在数量级上低于内存。所以事务性数据库如果强行改成单线程，就会极大的损害并发性能。

此外，单线程存储因为只能使用单线程，所以一个实例只能使用一个CPU核心。在多核心机器上就会浪费资源。所以往往要单机启用多个实例。而一旦启用多个实例就意味着要提前对数据进行Partition，分配给多个实例。但是Partition会造成单Partion查询方便，跨越多个Partition的查询麻烦的问题。所以简单的说，这条路子可以走，但是有比较大的局限性，比较适合为特定业务做定制存储。

另外一种办法是用存储过程将业务逻辑包起来丢给数据库执行。但这样做其实不现实，因为存储过程本身并不具备原子性和隔离性。为了让存储过程中执行是排他的，依然需要在存储过程里声明一个事务。如果必要，可以声明当前的事务隔离级别为Serializable以避免写前提困境。例如Mysql InnoDB可以这样写。

CREATE PROCEDURE foo_proc(  
IN param_1 INT,  
IN param_2 VARCHAR(100)  
)  
BEGIN
  SET TRANSACTION ISOLATION_LEVEL SERIALIZABLE; -- 可以设定下一个事务用Serializable隔离级别
  START TRANSACTION;
  -- 一系列操作代码……
  COMMIT;
END;  

这种做法其实等价于下面要讲的Serializable隔离级别。

顺便提一下，存储过程存在一系列使用上的问题，如不好开发，不好调试，不好版本管理，一旦写错可能会拖垮整个数据库服务器等。所以真的用起来先要仔细权衡是否值得使用它。

最后还有一个招数是用单SQL语句的事务。比如上面的计数器可以这样写：

UPDATE counter_tbl SET counter = counter + 1 where id = xxx;

这样写的确能保证排他性执行，因为这条语句自身可以成为一个事务，并且因为是UPDATE语句，所以必然会抢占X锁。锁的存在可以确保不会出现写前提困境。但这么做的前提是有办法把一个业务逻辑用一句修改类SQL表达。一个计数器的逻辑可以，但是复杂一些的业务就不行；或者在语法层面可行，但是写出来几百行的SQL，根本无法调试和维护。

加锁和基于锁的Serializable

通过加锁可以有效的排除所有可能的竞争问题。在MySQL InnoDB中，Serializable隔离级别是依靠MVCC + 加更多的锁。以下摘自MySQL的文档

• SERIALIZABLE

This level is like REPEATABLE READ, but InnoDB implicitly converts all plain SELECT statements to SELECT ... LOCK IN SHARE MODE if autocommit is disabled.

简单来讲就是所有的读取要加上共享锁。与MySQL不同，在PostgreSQL中，Serializable使用SSI实现，见下文的SSI的介绍。

数据库中经典的加锁的过程被称为两阶段加锁 (2 Phases Locking, 2PL)。注意这个词和两阶段提交（2PC）很像，但他们是截然不同的两个意思。所谓两阶段加锁是指：

• 加锁阶段：在事务过程中，根据不同的SQL指令加锁。
• 释放锁阶段：锁定直到这个事务被提交或者回滚（包括等待超时造成回滚）时释放。

基于锁的Serializable的实现准则是：读要block写，写也要block读，读不block读。

还是考虑上面计数器的例子，在MySQL InnoDB Serializable隔离级别下的过程。

事务A	事务B
get counter (counter = 1, 获取共享锁）
counter = counter + 1 (counter = 2)
set counter = 2 (获取排他锁，成功)
	get counter (counter = 1，获取共享锁，会被锁住)
commit（释放所有事务A的锁）	get counter返回，得到counter = 2; 同时获得了counter的共享锁。
	counter = counter + 1 (counter = 3)
	set counter = 3 (获取排他锁)
	commit

上面的例子解释了counter这条记录上的锁如何避免了counter的竞争问题。

实际上MySQL的Serializable除了锁记录，还会锁记录的间隙，避免意外的插入。这种锁概念上被称为区间锁(Range Lock)。MySQL InnoDB中的叫法是Gap Lock和Next-key Lock。

上文中有提到基于MVCC的Repeatable Read可以避免幻读。在基于锁的Serializable中做的更强硬，它会直接锁定以避免插入。

考虑下面的例子：

事务A	事务B
SELECT * FROM user WHERE age >= 20 and age <= 30; (获取区间锁)
	INSERT INTO user(id, name, age) VALUES(200, 'Jonh', 28); 被区间锁锁住
commit （释放掉锁）	INSERT获取锁定，并成功插入
	commit

在MySQL中，不同的隔离级别内部实现使用不同的MVCC读取策略+不同种类的锁来完成。这就好像你春节在饭馆吃饭，得点套餐一样。那么如果这些隔离级别没有一个满足心意，或者希望根据业务逻辑实现一些定制优化，是不是可以不可以DIY一下呢？是可以的：

SELECT ... LOCK IN SHARE MODE -- 尝试将查询符合条件的记录加上共享锁，如果锁已经被占了就等待
SELECT ... FOR UPDATE -- 尝试将符合查询条件的记录加上与等价UPDATE语句一样的锁，包括排他锁和区间锁

这些语句可以无视当前的隔离级别，完全按照你的心意来加锁。举个例子，假设有一个user数据表有id和name两列。id=3的name数据初始为"tom"。事务A和B都使用隔离级别Repeatable Read。

事务A	事务B
select name from user where id = 3; (得到"tom")
	update user set name = 'jack' where id = 3;
select name from user where id = 3; (得到“tom", 因为Repeatable Read的缘故)
select name from user where id = 3 for update; (会锁住，因为事务B已经获取了锁)
在MySQL中，上一句返回，并且会看到'jack'！	commit;

在MySQL中SELECT … FOR UPDATE会打破当前的Repeatable Read隔离级别，拿到另外一个事务提交的最新的数据；同样的行为在PostgreSQL执行的结果不同，PostgreSQL会检测出并发的数据修改而直接回滚事务。

基于锁的Serializable隔离级别，或者手工加锁，是可以根除任何并发冲突的，但是这是有代价的——大大的增加了锁的数量，同时也就增加了等待锁的时间以及死锁的机会。下面我们再看看SSI。

SSI和基于SSI实现的Serializable

相对于悲观锁的方案，相对应的乐观锁的方式就是SSI——Serialized Snopshot Isolation。它的大致意思是：本质上，整个事务还是Snapshot Isolation，但事务在进行过程中，除了对数据进行操作外，还要对整个事务的“写前提”——所有修改操作的依赖数据做追踪。当事务被commit时，当前事务会检查这个“写前提”是否被其他事务修改过，如果是，则回滚掉当前事务。PostgreSQL的Serializable基于SSI实现。

例如下面的是一个SSI隔离级别的例子。

事务A	事务B
get x (得到0)
	set x = 1
get x (得到0)	commit
set x = x + 3
commit (会失败，因为侦测到另外一个事务已经提交过修改后的x)

那么问题在于如何侦测到这个修改已经发生了？基本的办法有：

• 在一个事务进行提交时，对于所有修改的数据，查看MVCC中是否已经有其他的版本已经提交了但是本事务因为snapshot机制没有读取到
• 事务进行时，标记自身所有读取过的记录（就好像加共享锁，但是并不真的锁定什么）。另外一个事务如果提交了一个写操作，则反查这个写操作影响到的数据有哪些被读取中，并且读取他们的事务还没提交

SSI并非绝对优于锁的方案。悲观锁方案和乐观锁方案的权衡点在于，冲突是否足够多。如果冲突太多，SSI会造成大量的资源浪费（做了很多计算，但是就是commit不了）；如果冲突不是很多，加锁方案带来锁等待和死锁的负面效果更显著。所以在选取方案之前，先对业务造成的并发修改冲突量有一个估计。