MVCC的实现原理:
InnoDB对每一行都加上了两个隐藏的列,其中一列存储行被修改的时系统的修改版本号,另外一列存储行被删除时的系统的删除版本号,以此实现了读不加锁、读写不冲突(不需要等待访问行上的锁释放,读取行的一个快照)。在读多写少的应用中,读写不冲突是非常重要的,极大的增加了系统的并发性能。
MVCC的具体流程:
拿InnoDB在repeatable read隔离级别下来举例:
每当一个事务开始的时候,InnoDB都会给这个事务分配一个递增的版本号
在插入记录时,记录的创建版本号修改为当前事务版本号
在删除记录时,记录的删除版本号修改为当前事务版本号,做个删除的标记,在purge操作时才进行判断删除
在更新操作时,先标记旧记录为已删除,并将删除版本号改为当前事务版本号,然后插入一行新记录
在读取操作时,判断两个条件,都满足就返回(1、读取记录的修改版本号小于或等于当前事务版本号,即改行记录是在该事务中或者事务前进行修改 2、行的删除版本号要么没有被定义,即改行记录未被删除或更新,要么删除版本号大于当前事务版本号)
MVCC的优缺点:
优点:InnoDB几乎不用获得任何锁,每个查询都通过版本检查来获得自己需要的数据版本,从而大大提高系统的并发性
缺点:每行记录都需要额外的存储空间,更多的行检查工作和一些额外的维护工作
MVCC的注意事项:
各隔离级别MVCC的效果:
只有read-committed(读取的是行数据的最新版本)和 repeatable-read 两种事务隔离级别才能使用MVCC
read-uncommited由于是读到未提交的,所以不存在版本的问题
serializable 则会对所有读取的行加锁,也就没有必要用到MVCC
各隔离级别MVCC关于快照定义:
在read-committed隔离级别下,对于快照数据,mvcc总是读取被锁定行的最新一份快照数据
repeatable-read则是读取事务开始时的行数据版本
(注:如果有事务A进行select操作,事务B进行delect操作,那么当事务B提交后:如果在read-committed级别,则A读到最新数据历史数据(空集),而repeatable-read读到事务开始时的行数据版本,则还是和未提交前的一样)