MVCC—多版本并发控制机制

MVCC—多版本并发控制机制

一、简单理解MVCC

MVCC表示为多版本并发控制机制，我们的MySQL事务型存储引擎，例如我们的InnoDB，并不是仅仅使用一种简单的行锁机制，事实上，他们都和MVCC-多版本并发控制一起进行使用。

追溯原因，因为锁机制虽然能够控制并发操作，但是其系统开销较大，而我们的MVCC可以在大多数情况下代替行级锁，能够有效的降低系统的开销。

MVCC实现方式

MVCC是通过保存数据在某一个时间点的快照来实现的，不同的存储引擎的MVCC的实现也是不同的，典型的有乐观并发控制和悲观并发控制。

我们的通过MySQL的InnoDB存储引擎来分析MVCC是如何实现并发控制的【简单理解。底层并非如此实现的】。

MySQL中MVCC的具体实现

我们可以简单理解，InnoDB的MVCC,是通过在每行记录后面保存两个隐藏的列来实现的，这两个列，分别保存了这个行的创建时间和这个行的删除时间。这里存储的并不是实际的时间值,而是系统版本号(可以理解为事务的ID)，每当开始一个新的事务，系统版本号就会自动递增，事务开始时刻的系统版本号会作为事务的ID.下面看一下在REPEATABLE READ隔离级别（RR）下,MVCC具体是如何操作的。

我们先创建一个表tf_test：

CREATE TABLE tf_test(
	id INT(50) PRIMARY KEY AUTO_INCREMENT,
	test_name VARCHAR(50)
);

Insert操作

我们开启一个事务，插入几条数据：

START TRANSACTION;
INSERT INTO tf_test VALUES(NULL,'feng');
INSERT INTO tf_test VALUES(NULL,'tang');
COMMIT;

对应在数据中的表如下(我们假设事务ID从1开始，即当前插入的事务ID为1，后面两列是隐藏列,我们通过查询语句并看不到)：

id	tf_name	创建时间(事务ID)	删除时间(事务ID)
1	feng	1	undefined
2	tang	1	undefined

Select操作：

InnoDB会根据以下两个条件来检查每行的数据：

• InnoDB只会查找版本早于当前事务版本的数据行，也就说行的系统版本小于或者等于当前事务的系统版本号，这样可以保证事务读取的行，要么是在事务开始之前就已经存在的，要么事务自身插入或者修改的。

• 行的删除版本要么未定义，要么大于当前事务版本号，这样可以保证事务读取的行，在事务开始之前未被删除。

我们说只有上面两个条件同时满足的话，才可以作为查询的结果返回！！！

Delete操作

InnoDB会为删除的每一行保存当前系统的的版本号（事务的ID）作为删除的标识。

具体案例

下面进行数据的查询，我们假设该事务的事务ID为2：

start transaction;
select * from tf_test;  （1）
select * from tf_test;  （2）
commit;

场景1：

我们假设上面的事务刚好执行到（1）时，此时另一个事务ID为3的事务向表中插入一条数据：

start transaction;
insert into tf_test values(NULL,'ai');
commit;

此时我们的表中数据为：

id	tf_name	创建时间(事务ID)	删除时间(事务ID)
1	feng	1	undefined
2	tang	1	undefined
3	ai	3	undefined

然后我们接着执行事务ID为2的查询操作的（2），由于id = 3的创建时间（事务ID为3），执行当前事务的事务ID为2，而我们的InnoDB只会查找事务ID小于等于当前事务ID的数据行，故我们的id = 4的数据行并不会在执行事务ID为2的查询操作中被查询出来，因为事务ID为2的两条select语句查询的结果均为下表的数据：

id	tf_name	创建时间(事务ID)	删除时间(事务ID)
1	feng	1	undefined
2	tang	1	undefined

并不会有我们的在事务ID为3的事务中插入的数据：

id	tf_name	创建时间(事务ID)	删除时间(事务ID)
3	ai	3	undefined

场景2：

现在假设我们在这个事务ID为2的事务执行过程中，刚执行到（1），此时事务3执行完了，又去执行事务4（事务ID = 4）

start transaction;  
delete from tf_test where id = 1;
commit; 

此时我们的数据库的表中数据如下所示：

id	tf_name	创建时间(事务ID)	删除时间(事务ID)
1	feng	1	4
2	tang	1	undefined
3	ai	3	undefined

接着我们再执行事务ID为2的事务的步骤（2），此时根据我们的检索条件，它会检索创建时间小于等于当前事务ID，删除时间大于当前事务ID的行，而此时我们删除id = 1的行是在事务ID = 4 的事务中进行的，故事务ID = 2的查询还会查询id = 1的数据行：

id	tf_name	创建时间(事务ID)	删除时间(事务ID)
1	feng	1	4
2	tang	1	undefined

Update操作

InnoDB执行UPDATE操作，实际上是新插入了一行记录，并保存其创建时间为当前事务的ID，同时保存当前事务ID到要UPDATE的行的删除时间.

场景3:

此时我们在执行完事务2的（1）以后，其他用户线程接连执行了事务3，4，此时又有一个用户线程进行了Update操作，我们将其命令为事务5（即事务ID = 5）：

start  transaction;
update tf_test set name='test' where id=2;
commit;

此时根据update的更新原则，我们会生成一个新的一行，并修改原来行的删除时间以及当前行的创建时间

id	tf_name	创建时间(事务ID)	删除时间(事务ID)
1	feng	1	4
2	tang	1	5
3	ai	3	undefined
4	test	5	undefined

而此时会继续执行事务ID为2的（2），查询的结果为：

id	tf_name	创建时间(事务ID)	删除时间(事务ID)
1	feng	1	4
2	tang	1	5

此时我们查询到的数据还是更新之前的数据…

二、深入底层理解MVCC

MVCC介绍

MVCC，全称Multi-Version Concurrency Control，即多版本并发控制。MVCC是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。

其中，MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读。

MySQL InnoDB下的当前读和快照读

当前读

像select lock in share mode(共享锁), select for update ; update, insert ,delete(排他锁)这些操作都是一种当前读，为什么叫当前读？

就是它读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁

快照读

像不加锁的select操作就是快照读，即不加锁的非阻塞读；快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读；之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，即MVCC，可以认为MVCC是行锁的一个变种，但它在很多情况下，避免了加锁操作，降低了开销；既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本

当前读，快照读和MVCC的关系

准确的说，MVCC多版本并发控制指的是 “维持一个数据的多个版本，使得读写操作没有冲突” 这么一个概念。仅仅是一个理想概念。

而在MySQL中，实现这么一个MVCC理想概念，我们就需要MySQL提供具体的功能去实现它，而快照读就是MySQL为我们实现MVCC理想模型的其中一个具体非阻塞读功能。而相对而言，当前读就是悲观锁的具体功能实现

要说的再细致一些，快照读本身也是一个抽象概念，再深入研究。MVCC模型在MySQL中的具体实现则是由 3个隐式字段，undo日志 ，Read View 等去完成的，具体可以看下面的MVCC实现原理

MVCC的好处

数据库并发场景有三种，分别为：

• 读-读：不存在任何问题，也不需要并发控制
• 读-写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读
• 写-写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失

MVCC的好处

多版本并发控制（MVCC）是一种用来解决读-写冲突的无锁并发控制，也就是为事务分配单向增长的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，读操作只读该事务开始前的数据库的快照。 所以MVCC可以为数据库解决以下问题

• 在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能
• 同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题

在数据库中，因为有了MVCC，所以我们可以形成两个组合：

• MVCC + 悲观锁

  MVCC解决读写冲突，悲观锁解决写写冲突

• MVCC + 乐观锁

  MVCC解决读写冲突，乐观锁解决写写冲突

MVCC的实现原理

MVCC的目的就是多版本并发控制，在数据库中的实现，就是为了解决读写冲突，它的实现原理主要是依赖记录中的 3个隐式字段，undo日志 ，Read View 来实现的

隐藏字段

每行记录除了我们自定义的字段外，还有数据库隐式定义的DB_TRX_ID，DB_ROLL_PTR，DB_ROW_ID等字段

• DB_ROW_ID
  6byte，隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB会自动以DB_ROW_ID产生一个聚簇索引
  实际还有一个删除flag隐藏字段, 既记录被更新或删除并不代表真的删除，而是删除flag变了
• DB_TRX_ID
  6byte，最近修改(修改/插入)事务ID：记录创建这条记录/最后一次修改该记录的事务ID
• DB_ROLL_PTR
  7byte，回滚指针，指向这条记录的上一个版本（存储于rollback segment里）

如上图所示：DB_ROW_ID是数据库默认为该行记录生成的唯一隐式主键，DB_TRX_ID是当前操作该记录的事务ID,而DB_ROLL_PTR是一个回滚指针，用于配合undo日志，指向上一个旧版本

undo日志

undo log主要分为两种：

• insert undo log
  代表事务在insert新记录时产生的undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃
• update undo log
  事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除

purge线程介绍:

* 从前面的分析可以看出，为了实现InnoDB的MVCC机制，更新或者删除操作都只是设置一下老记录的deleted_bit，并不真正将过时的记录删除。

* 为了节省磁盘空间，InnoDB有专门的purge线程来清理deleted_bit为true的记录。为了不影响MVCC的正常工作，purge线程自己也维护了一个read view（这个read view相当于系统中最老活跃事务的read view）;如果某个记录的deleted_bit为true，并且DB_TRX_ID相对于purge线程的read view可见，那么这条记录一定是可以被安全清除的

案例说明：

一、比如一个有个事务插入persion表插入了一条新记录，记录如下，name为Jerry, age为24岁，隐式主键是1，事务ID和回滚指针，我们假设为NULL

二、 现在来了一个事务1对该记录的name做出了修改，改为Tom

• 在事务1修改该行(记录)数据时，数据库会先对该行加排他锁【写锁】
• 然后把该行数据拷贝到undo log中，作为旧记录，既在undo log中有当前行的拷贝副本
• 拷贝完毕后，修改该行name为Tom，并且修改隐藏字段的事务ID为当前事务1的ID, 我们默认从1开始，之后递增，回滚指针指向拷贝到undo log的副本记录，既表示我的上一个版本就是它
• 事务提交后，释放锁

三、 又来了个事务2修改person表的同一个记录，将age修改为30岁

• 在事务2修改该行数据时，数据库也先为该行加排他锁
• 然后把该行数据拷贝到undo log中，作为旧记录，发现该行记录已经有undo log了，那么最新的旧数据作为链表的表头，插在该行记录的undo log最前面
• 修改该行age为30岁，并且修改隐藏字段的事务ID为当前事务2的ID, 那就是2，回滚指针指向刚刚拷贝到undo log的副本记录
  事务提交，释放锁

从上面，我们就可以看出，不同事务或者相同事务的对同一记录的修改，会导致该记录的undo log成为一条记录版本线性表，既链表，undo log的链首就是最新的旧记录，链尾就是最早的旧记录（当然就像之前说的该undo log的节点可能是会purge线程清除掉，像图中的第一条insert undo log，其实在事务提交之后可能就被删除丢失了，不过这里为了演示，所以还放在这里）

Read View(读视图)

什么是Read View，说白了Read View就是事务进行快照读操作的时候生产的读视图(Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID(当每个事务开启时，都会被分配一个ID, 这个ID是递增的，所以最新的事务，ID值越大)

所以我们知道 Read View主要是用来做可见性判断的, 即当我们某个事务执行快照读的时候，对该记录创建一个Read View读视图，把它比作条件用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的undo log里面的某个版本的数据。

Read View遵循一个可见性算法，主要是将要被修改的数据的最新记录中的DB_TRX_ID取出来，与系统当前其他活跃事务的ID去对比（由Read View维护），如果DB_TRX_ID跟Read View的属性做了某些比较，不符合可见性，那就通过DB_ROLL_PTR回滚指针去取出Undo Log中的DB_TRX_ID再比较，即遍历链表的DB_TRX_ID（从链首到链尾，即从最近的一次修改查起），直到找到满足特定条件的DB_TRX_ID, 那么这个DB_TRX_ID所在的旧记录就是当前事务能看见的最新老版本。

我们可以简化Read View理解为三个全局属性：

• trx_list（名字我随便取的）
  一个数值列表，用来维护Read View生成时刻系统正活跃的事务ID
• up_limit_id
  记录trx_list列表中事务ID最小的ID
• low_limit_id
  ReadView生成时刻系统尚未分配的下一个事务ID，也就是目前已出现过的事务ID的最大值 + 1

• 首先比较DB_TRX_ID 是否小于up_limit_id, 如果小于，则当前事务能看到DB_TRX_ID 所在的记录，如果大于等于进入下一个判断

• 接下来判断 DB_TRX_ID 是否大于等于 low_limit_id , 如果大于等于则代表DB_TRX_ID所在的记录在Read View生成后才出现的，那对当前事务肯定不可见，如果小于则进入下一个判断

• 判断DB_TRX_ID 是否在活跃事务之中，trx_list.contains(DB_TRX_ID)，如果在，则代表我Read View生成时刻，你这个事务还在活跃，还没有Commit，你修改的数据，我当前事务也是看不见的；如果不在，则说明，你这个事务在Read View生成之前就已经Commit了，你修改的结果，我当前事务是能看见的

整体流程

我们在了解了隐式字段，undo log， 以及Read View的概念之后，就可以来看看MVCC实现的整体流程是怎么样了

整体的流程是怎么样的呢？我们可以模拟一下

当事务2对某行数据执行了快照读，数据库为该行数据生成一个Read View读视图，假设当前事务ID为2，此时还有事务1和事务3在活跃中，事务4在事务2快照读前一刻提交更新了，所以Read View记录了系统当前活跃事务1，3的ID，维护在一个列表上，假设我们称为trx_list

事务1	事务2	事务3	事务4
事务开始	事务开始	事务开始	事务开始
…	…	…	修改且已提交
进行中	快照读	进行中
…	…	…

• Read View不仅仅会通过一个列表trx_list来维护事务2执行快照读那刻系统正活跃的事务ID，还会有两个属性up_limit_id（记录trx_list列表中事务ID最小的ID），low_limit_id(记录trx_list列表中事务ID最大的ID，也有人说快照读那刻系统尚未分配的下一个事务ID也就是目前已出现过的事务ID的最大值+1；所以在这里例子中up_limit_id就是1，low_limit_id就是4 + 1 = 5，trx_list集合的值是1,3，Read View如下图

• 我们的例子中，只有事务4修改过该行记录，并在事务2执行快照读前，就提交了事务，所以当前该行当前数据的undo log如下图所示；我们的事务2在快照读该行记录的时候，就会拿该行记录的DB_TRX_ID去跟up_limit_id，low_limit_id和活跃事务ID列表(trx_list)进行比较，判断当前事务2能看到该记录的版本是哪个。

• 所以先拿该记录DB_TRX_ID字段记录的事务ID 4去跟Read View的的up_limit_id比较，看4是否小于up_limit_id(1)，所以不符合条件，继续判断 4 是否大于等于 low_limit_id(5)，也不符合条件，最后判断4是否处于trx_list中的活跃事务, 最后发现事务ID为4的事务不在当前活跃事务列表中, 符合可见性条件，所以事务4修改后提交的最新结果对事务2快照读时是可见的，所以事务2能读到的最新数据记录是事务4所提交的版本，而事务4提交的版本也是全局角度上最新的版本

也正是Read View生成时机的不同，从而造成RC,RR级别下快照读的结果的不同

RR是如何在RC级的基础上解决不可重复读的？

RR级别下：

表1:

事务A	事务B
开启事务	开启事务
快照读(无影响)查询金额为500	快照读查询金额为500
更新金额为400
提交事务
	select 快照读金额为500
	select lock in share mode当前读金额为400

在上表的顺序下，事务B的在事务A提交修改后的快照读是旧版本数据，而当前读是实时新数据400

RC级别下：

事务A	事务B
开启事务	开启事务
快照读（无影响）查询金额为500
更新金额为400
提交事务
	select 快照读金额为400
	select lock in share mode当前读金额为400

而在表2这里的顺序中，事务B在事务A提交后的快照读和当前读都是实时的新数据400，这是为什么呢？

答：这里与上表的唯一区别仅仅是表1的事务B在事务A修改金额前快照读过一次金额数据，而表2的事务B在事务A修改金额前没有进行过快照读。

故我们通过上面的简单的不可重复读场景就知道了事务中快照读的结果是非常依赖该事务首次出现快照读的地方，即某个事务中首次出现快照读的地方非常关键，它有决定该事务后续快照读结果的能力。

我们这里测试的是更新，同时删除和更新也是一样的，如果事务B的快照读是在事务A操作之后进行的，事务B的快照读也是能读取到最新的数据的

RC,RR级别下的InnoDB快照读有什么不同？

正是Read View生成时机的不同，从而造成RC,RR级别下快照读的结果的不同

• 在RR级别下的某个事务的对某条记录的第一次快照读会创建一个快照及Read View, 将当前系统活跃的其他事务记录起来，此后在调用快照读的时候，还是使用的是同一个Read View，所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个Read View，所以对之后的修改不可见；
• 即RR级别下，快照读生成Read View时，Read View会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见
• 而在RC级别下的，事务中，每次快照读都会新生成一个快照和Read View, 这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因
• 总之在RC隔离级别下，是每个快照读都会生成并获取最新的Read View；而在RR隔离级别下，则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。
  用的是同一个Read View**，所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个Read View，所以对之后的修改不可见；
• 即RR级别下，快照读生成Read View时，Read View会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见
• 而在RC级别下的，事务中，每次快照读都会新生成一个快照和Read View, 这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因
• 总之在RC隔离级别下，是每个快照读都会生成并获取最新的Read View；而在RR隔离级别下，则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。