MYSQL中的乐观锁实现(MVCC)简析

什么是MVCC

MVCC即Multi-Version Concurrency Control，中文翻译过来叫多版本并发控制。

MVCC是解决了什么问题

众所周知，在MYSQL中，MyISAM使用的是表锁，InnoDB使用的是行锁。而InnoDB的事务分为四个隔离级别，其中默认的隔离级别REPEATABLE READ须要两个不一样的事务相互之间不能影响，并且还能支持并发，这点悲观锁是达不到的，因此REPEATABLE READ采用的就是乐观锁，而乐观锁的实现采用的就是MVCC。正是由于有了MVCC，才造就了InnoDB强大的事务处理能力。

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. 行的删除版本要么未定义,要么大于当前事务版本号(这能够确保事务读取到的行，在事务开始以前未被删除)，
   只有条件一、2同时知足的记录，才能返回做为查询结果.

DELETE

InnoDB会为删除的每一行保存当前系统的版本号(事务的ID)做为删除标识.

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

start transaction; 
select * from yang; 
select * from yang; 
commit;

假设1:
假设在执行这个事务ID为2的过程当中,刚执行到(1),这时,有另外一个事务ID为3往这个表里插入了一条数据; 第三个事务ID为3;

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

这时表中的数据以下:

id	name	建立时间(事务ID)	删除时间(事务ID)
1	yang	1	undefined
2	long	1	undefined
3	fei	1	undefined
4	tian	3	undefined

而后接着执行事务2中的(2),因为id=4的数据的建立时间(事务ID为3),执行当前事务的ID为2,而InnoDB只会查找事务ID小于等于当前事务ID的数据行,因此id=4的数据行并不会在执行事务2中的(2)被检索出来,在事务2中的两条select 语句检索出来的数据以下:

id	name	建立时间(事务ID)	删除时间(事务ID)
1	yang	1	undefined
2	long	1	undefined
3	fei	1	undefined

假设2
假设在执行这个事务ID为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

接着执行事务ID为2的事务(2),根据SELECT 检索条件能够知道,它会检索建立时间(建立事务的ID)小于当前事务ID的行和删除时间(删除事务的ID)大于当前事务的行,而id=4的行上面已经说过,而id=1的行因为删除时间(删除事务的ID)大于当前事务的ID,因此事务2的(2)select * from yang也会把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
2	Long	5	undefined

继续执行事务2的(2),根据select 语句的检索条件,获得下表:

id	name	建立时间(事务ID)	删除时间(事务ID)
1	yang	1	4
2	long	1	5
3	fei	1	undefined

仍是和事务2中(1)select 获得相同的结果.