MVCC是一种多版本并发控制机制。java
大多数的MYSQL事务型存储引擎,如,InnoDB,Falcon以及PBXT都不使用一种简单的行锁机制.事实上,他们都和MVCC–多版本并发控制来一块儿使用.
你们都应该知道,锁机制能够控制并发操做,可是其系统开销较大,而MVCC能够在大多数状况下代替行级锁,使用MVCC,能下降其系统开销.数据库
MVCC是经过保存数据在某个时间点的快照来实现的. 不一样存储引擎的MVCC. 不一样存储引擎的MVCC实现是不一样的,典型的有乐观并发控制和悲观并发控制.并发
下面,咱们经过InnoDB的MVCC实现来分析MVCC使怎样进行并发控制的.
InnoDB的MVCC,是经过在每行记录后面保存两个隐藏的列来实现的,这两个列,分别保存了这个行的建立时间,一个保存的是行的删除时间。这里存储的并非实际的时间值,而是系统版本号(能够理解为事务的ID),没开始一个新的事务,系统版本号就会自动递增,事务开始时刻的系统版本号会做为事务的ID.下面看一下在REPEATABLE READ隔离级别下,MVCC具体是如何操做的..net
create table yang(
id int primary key auto_increment,
name varchar(20));code
假设系统的版本号从1开始.
InnoDB为新插入的每一行保存当前系统版本号做为版本号.
第一个事务ID为1;blog
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会根据如下两个条件检查每行记录:
a.InnoDB只会查找版本早于当前事务版本的数据行(也就是,行的系统版本号小于或等于事务的系统版本号),这样能够确保事务读取的行,要么是在事务开始前已经存在的,要么是事务自身插入或者修改过的.
b.行的删除版本要么未定义,要么大于当前事务版本号,这能够确保事务读取到的行,在事务开始以前未被删除.
只有a,b同时知足的记录,才能返回做为查询结果.rem
InnoDB会为删除的每一行保存当前系统的版本号(事务的ID)做为删除标识.
看下面的具体例子分析:
第二个事务,ID为2;get
start transaction; select * from yang; //(1) select * from yang; //(2) commit;
假设在执行这个事务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 | 1 | 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 |
假设在执行这个事务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 | 1 | 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 |
InnoDB执行UPDATE,其实是新插入了一行记录,并保存其建立时间为当前事务的ID,同时保存当前事务ID到要UPDATE的行的删除时间.
假设在执行完事务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 | 1 | undefined |
2 | long | 1 | undefined |
继续执行事务2的(2),根据select 语句的检索条件,获得下表:
id | name | 建立时间(事务ID) | 删除时间(事务ID) |
---|---|---|---|
1 | yang | 1 | 4 |
2 | long | 1 | 5 |
3 | fei | 1 | undefined |
仍是和事务2中(1)select 获得相同的结果.
————————————————
版权声明:本文为CSDN博主「杨龙飞的博客」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处连接及本声明。
原文连接:https://blog.csdn.net/whoamiy...