MySQL的MVCC(多版本并发控制)

InnoDB的MVCC，通过在每行纪录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存了行的过期时间，（存储的并不是实际的时间值，而是系统版本号）。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行纪录的版本号进行比较,使用之后RR（可重复读）隔离级别下是不会出现幻读的现象。在REPEATABLE READ隔离级别下，MVCC具体的操作如下：

简单来说就是

其实就是在每一行记录的后面增加两个隐藏列，记录创建版本号和删除版本号，而每一个事务在启动的时候，都有一个唯一的递增的版本号。 

INSERT :记录的创建版本号就是事务版本号

比如我插入一条记录, 事务id 假设是1 ，那么记录如下：也就是说，创建版本号就是事务版本号。

id	name	create version	delete version
1	test	1

 

UPDATE :

采用的是先标记旧的那行记录为已删除，并且删除版本号是事务版本号，然后插入一行新的记录的方式。 

比如，针对上面那行记录，事务Id为2 要把name字段更新

update table set name= 'new_value' where id=1;

id	name	create version	delete version
1	test	1	2
1	new_value	2

 

 

 DELETE :

就把事务版本号作为删除版本号。比如

delete from table where id=1; 

 

id	name	create version	delete version
1	new_value	2	3

 

• SELECT 
  InnoDB会根据以下两个条件检查每行纪录： 
  1. InnoDB只查找版本早于当前事务版本的数据行，即，行的系统版本号小于或等于事务的系统版本号，这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。
  2. 行的删除版本，要么未定义，要么大于当前事务版本号。这样可以确保事务读取到的行，在事务开始之前未被删除。

只有符合上述两个条件的纪录，才能作为查询结果返回。

这样就保证了各个事务互不影响。从这里也可以体会到一种提高系统性能的思路，就是： 

通过版本号来减少锁的争用。

另外，只有read-committed和 repeatable-read 两种事务隔离级别才能使用mVcc

read-uncommited由于是读到未提交的，所以不存在版本的问题

而serializable 则会对所有读取的行加锁。