MVCC (Multi-Version Concurrency Control) 是一种多版本并发控制机制。
大多数的 MySQL 事务型存储引擎,如,InnoDB,Falcon 以及 PBXT 都不使用一种简单的行锁机制。事实上,他们都和 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开始
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 |
InnoDB 会根据以下两个条件检查每行记录:
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 |
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 |