MVCC概念:
被称为多版本并发控制,是一种并发控制的方法,一般在数据库管理系统中,实现对数据库的并发访问;与大多数的MySQL事务型存储引擎的行级锁配合使用
MVCC实现原理:
MVCC是通过保存数据在某个时间点的快照来实现的,MVCC主要是为Repeatable-Read(可避免脏独,不可重复读情况的发生)事务隔离级别做的,在此隔离级别下,a和b客户端所示的数据相互隔离,互相更新不可见。
扩展：
脏读: 没提交的数据被读出来了
不可重读: 前后多次读取,数据内容不一样(同一个会话中,在不进行修改的时候,永远只看到同样的一套数据)
幻读: 前后多次读取,数据总量不一样
Serializable：可避免脏读、不可重复读、虚读情况的发生。（串行化）
Repeatable read：可避免脏读、不可重复读情况的发生。（可重复读）不可以避免虚读
Read committed：可避免脏读情况发生（读已提交）
Read uncommitted：最低级别，以上情况均无法保证。(读未提交)
MVCC的应用：
以innodb为例来讲MVCC的使用
INSERT
InnoDB为新插入的每一行保存当前系统版本号作为版本号.
第一个事务ID为1；
|
1 2 3 4 5 |
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会根据以下两个条件检查每行记录:
a.InnoDB只会查找版本早于当前事务版本的数据行(也就是,行的系统版本号小于或等于事务的系统版本号)，这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的.
b.行的删除版本要么未定义,要么大于当前事务版本号,这可以确保事务读取到的行，在事务开始之前未被删除.
只有a,b同时满足的记录，才能返回作为查询结果.
DELETE
InnoDB会为删除的每一行保存当前系统的版本号(事务的ID)作为删除标识.
看下面的具体例子分析:
第二个事务,ID为2;
|
1 2 3 4 |
start transaction; select * from yang; //(1) select * from yang; //(2) commit; |
假设1
假设在执行这个事务ID为2的过程中,刚执行到(1),这时,有另一个事务ID为3往这个表里插入了一条数据;
第三个事务ID为3;
|
1 2 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;
第四个事务:
|
1 2 3 |
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个事务:
|
1 2 3 |
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 |