轻松理解 MySQL MVCC（Multi-Version Concurrency Control） 多版本并发控制实现机制

MVCC 简介

• 什么是 MVCC？

MVCC （Multi-Version Concurrency Control） 是一种多版本并发控制机制。

• MVCC 是为了解决什么问题?

大多数的 MySQL 事务型存储引擎，如，InnoDB，Falcon 以及 PBXT 都不使用一种简单的行锁机制。事实上，他们都和 MVCC 来一起使用的。

大家都应该知道，锁机制可以控制并发操作，但是其系统开销较大，而 MVCC 可以在大多数情况下代替行级锁，使用 MVCC，能降低其系统开销。

• MVCC 实现

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

MVCC 具体实现分析

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

简单的小例子

create table yang(
	id int primary key auto_increment, 
	name varchar(20)
);

假设系统的版本号从1开始

INSERT

InnoDB 为新插入的每一行保存当前系统版本号作为版本号，第一个事务 ID 为 1。

start transaction;
insert into yang values(NULL,'yang') ;
insert into yang values(NULL,'long');
insert into yang values(NULL,'fei');
commit;

对应在数据中的表如下（后面两列是隐藏列，我们通过查询语句并看不到）

id	name	创建时间（事务 ID）	删除时间（事务 ID）
1	yang	1	undefined
2	long	1	undefined
3	fei	1	undefined

SELECT

InnoDB 会根据以下两个条件检查每行记录：

1. InnoDB 只会查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。
2. 行的删除版本要么未定义，要么大于当前事务版本号，这可以确保事务读取到的行，在事务开始之前未被删除。
   只有 1、2 同时满足的记录，才能返回作为查询结果。

INSERT/DELETE

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

看下面的具体例子分析，第二个事务，ID 为 2。

start transaction;
select * from yang;  //(1)
select * from yang;  //(2)
commit; 

假设 1：

假设在执行这个 ID 为 2 的事务的过程中，刚执行到（1），这时，有另一个 ID 为 3 的事务往这个表里插入了一条数据。

start transaction;
insert into yang values(NULL,'tian');
commit;

id	name	创建时间（事务 ID）	删除时间（事务 ID）
1	yang	1	4
2	long	1	undefined
3	fei	1	undefined
4	tian	3	undefined

然后接着事务 2 执行（2），由于 id=4 的数据的创建时间（事务 3）大于执行当前事务ID（事务 2），而 InnoDB 只会查找事务 ID 小于等于当前事务 ID 的数据行，所以 id=4 的数据行并不会在 事务 2 执行（2）时被检索出来，在 ID 为 2 的事务中的两条 select 语句检索出来的数据都一样，如下表所示:

id	name	创建时间（事务 ID）	删除时间（事务 ID）
1	yang	1	undefined
2	long	1	undefined
3	fei	1	undefined
4	tian	3	undefined

假设 2：

假设在执行事务 2 的过程中，刚执行到（1），假设执行完事务 3 后，接着又执行了事务 4：

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

此时数据库中的表如下：

id	name	创建时间（事务 ID）	删除时间（事务 ID）
1	yang	1	4
2	long	1	undefined
3	fei	1	undefined
4	tian	3	undefined

接着执行事务 2 中的（2），根据 SELECT 检索条件可以知道，它会检索创建时间小于当前事务 ID 的行和删除时间大于当前事务的行，而 id=4 的行上面已经说过，而 id=1 的行由于删除时间大于当前事务的 ID，所以事务 2 中的（2）也会把 id=1 的数据检索出来。所以，事务 2 中的两条 select 语句检索出来的数据都一样，如下表所示：

id	name	创建时间（事务 ID）	删除时间（事务 ID）
1	yang	1	4
2	long	1	undefined
3	fei	1	undefined

UPDATE

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

假设 3：
假设在执行完事务 2 的（1）后，其它用户执行完事务 3，4后，又有一个用户对这张表执行了 UPDATE 操作。

第5个事务:

start transaction;
update yang set name='Long' where id=2;
commit;

根据 UPDATE 的更新原则：会生成新的一行，并在原来要修改的列的删除时间列上添加本事务ID，得到表如下：

id	name	创建时间（事务 ID）	删除时间（事务 ID）
1	yang	1	4
2	long	1	5
3	fei	1	undefined
4	tian	3	undefined
5	Long	5	undefined

继续执行事务 2 中的（2），根据 select 语句的检索条件，得到下表:

id	name	创建时间（事务 ID）	删除时间（事务 ID）
1	yang	1	4
2	long	1	5
3	fei	1	undefined