什么是MVCC
MVCC即Multi-Version Concurrency Control,中文翻译过来叫多版本并发控制。
MVCC解决的问题
MySQl默认的存储引擎是InnoDB,默认的事务隔离级别是REPEATABLE RED(可重复度),这种事务隔离级别要求2个事务之间不能影响,而且还能支持并发,悲观锁无法达到这个性能要求。所以该隔离级别采用的是乐观锁的形式实现的,乐观锁采用的具体实现方式是:MVCCC
MVCC具体实现
InnoDB的MVCC是通过在每一行记录的后面保存2个隐藏的列来实现的。这2个列,一个保存了行的创建时间,一个保存了行的过期时间(删除时间)。这里储存的并不是世纪的时间值,而是系统版本号。每开始一个事务,系统版本号自动递增。事务开始时刻的版本号会作为当前事务的版本号(也可以理解为ID)
MVCC具体实现举例:
创建一张Person表:
create table Person(
id int primary key auto_increment,
name varchar(20)
);
假设系统的版本号从1开始
insert
InnoDB为新插入的每一行保存当前系统版本号作为版本号。第一个事务ID为1:
start transaction
insert into Person values(null,"zs");
insert into Person values(null,"ls");
insert into Person values(null,"ww");
commit
对应在数据中的表如下(后面两列是隐藏列,我们通过查询语句并看不到)
id | name | 创建时间(事务ID) | 删除时间(事务ID) |
---|---|---|---|
1 | zs | 1 | undefined |
2 | ls | 1 | undefined |
3 | ww | 1 | undefined |
select
- InnoDB只会查找版本早于当前事务版本的数据行(也就是行的系统版本号小于或等于当前事务的版本号),这样可以确保事务读取到的行,要么是事务开始前就已经存在的,要么是事务自生插入或修改过的。
- 行的删除版本要么未定义(还没有数据对他进行删除操作),要么大于当前事务版本号(这样可以确保当前事务读到的行,在该事务之前未被删除)。
只有符合上述2个条件的记录,才能作为结果返回给查询
delete
InnoDB会为删除的每一行保存当前系统的版本号(事务ID)作为标识。
第二个事务:ID为2
start transaction;
select * from Person;
select * from Person;
commit;
假设1:
假设在执行这个事务ID为2的过程中,刚执行到(1),这时,有另一个事务ID为3往这个表里插入了一条数据; 第三个事务ID为3;
start transaction;
insert into Person values(NULL,'tian');
commit;
这时表中的数据如下:
id | name | 创建时间(事务ID) | 删除时间(事务ID) |
---|---|---|---|
1 | zs | 1 | undefined |
2 | ls | 1 | undefined |
3 | ww | 1 | undefined |
4 | tain | 3 | undefined |
然后接着执行事务2中的(2),由于id=4的数据的创建时间(事务ID为3),执行当前事务的ID为2,而InnoDB只会查找事务ID小于等于当前事务ID的数据行,所以id=4的数据行并不会在执行事务2中的(2)被检索出来,在事务2中的两条select 语句检索出来的数据如下:
id | name | 创建时间(事务ID) | 删除时间(事务ID) |
---|---|---|---|
1 | zs | 1 | undefined |
2 | ls | 1 | undefined |
3 | ww | 1 | undefined |
假设2
假设在执行这个事务ID为2的过程中,刚执行到(1),假设事务执行完事务3后,接着又执行了事务4;
第四个事务: ID为4
start transaction;
delete from Person where id=1;
commit;
此时数据库中的表如下:
id | name | 创建时间(事务ID) | 删除时间(事务ID) |
---|---|---|---|
1 | zs | 1 | 4 |
2 | ls | 1 | undefined |
3 | ww | 1 | undefined |
4 | tain | 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 | zs | 1 | 4 |
2 | ls | 1 | undefined |
3 | ww | 1 | undefined |
UPDATE
InnoDB执行UPDATE,实际上是新插入了一行记录,并保存其创建时间为当前事务的ID,同时保存当前事务ID到要UPDATE的行的删除时间。
假设3:
假设在执行完事务2的(1)后又执行,其它用户执行了事务3,4,这时,又有一个用户对这张表执行了UPDATE操作:
第5个事务:ID为5
start transaction;
update Person set name='Long' where id=2;
commit;
根据update的更新原则:会生成新的一行,并在原来要修改的列的删除时间列上添加本事务ID,得到表如下:
id | name | 创建时间(事务ID) | 删除时间(事务ID) |
---|---|---|---|
1 | zs | 1 | 4 |
2 | ls | 1 | 5 |
3 | ww | 1 | undefined |
4 | tain | 3 | undefined |
2 | Long | 5 | undefined |
继续执行事务2的(2),根据select 语句的检索条件,得到下表:
id | name | 创建时间(事务ID) | 删除时间(事务ID) |
---|---|---|---|
1 | zs | 1 | 4 |
2 | ls | 1 | 5 |
3 | ww | 1 | undefined |
还是和事务2中(1)select 得到相同的结果.
参考文章:
https://www.cnblogs.com/pautcher/p/7723422.html
https://segmentfault.com/a/1190000009374567
参考书籍:《高性能MySQL》