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会根据以下两个条件检查每行纪录:- InnoDB只查找版本早于当前事务版本的数据行,即,行的系统版本号小于或等于事务的系统版本号,这样可以确保事务读取的行,要么是在事务开始前已经存在的,要么是事务自身插入或者修改过的。
- 行的删除版本,要么未定义,要么大于当前事务版本号。这样可以确保事务读取到的行,在事务开始之前未被删除。
只有符合上述两个条件的纪录,才能作为查询结果返回。
这样就保证了各个事务互不影响。从这里也可以体会到一种提高系统性能的思路,就是:
通过版本号来减少锁的争用。
另外,只有read-committed和 repeatable-read 两种事务隔离级别才能使用mVcc
read-uncommited由于是读到未提交的,所以不存在版本的问题
而serializable 则会对所有读取的行加锁。