mysql的MVCC多版本并发控制的实现

吾爱主题阅读：185 2024-04-02 08:01:26 评论：0

1 什么是mvcc

mvcc全称是： multiversion concurrency control，多版本并发控制，提供并发访问数据库时，对事务内读取的到的内存做处理，用来避免写操作堵塞读操作的并发问题。

举个例子，程序员a正在读数据库中某些内容，而程序员b正在给这些内容做修改（假设是在一个事务内修改，大概持续10s左右），a在这10s内则可能看到一个不一致的数据，在b没有提交前，如何让a能够一直读到的数据都是一致的呢？

有几种处理方法，第一种：基于锁的并发控制，程序员b开始修改数据时，给这些数据加上锁，程序员a这时再读，就发现读取不了，处于等待情况，只能等b操作完才能读数据，这保证a不会读到一个不一致的数据，但是这个会影响程序的运行效率。还有一种就是：mvcc，每个用户连接数据库时，看到的都是某一特定时刻的数据库快照，在b的事务没有提交之前，a始终读到的是某一特定时刻的数据库快照，不会读到b事务中的数据修改情况，直到b事务提交，才会读取b的修改内容。

一个支持mvcc的数据库，在更新某些数据时，并非使用新数据覆盖旧数据，而是标记旧数据是过时的，同时在其他地方新增一个数据版本。因此，同一份数据有多个版本存储，但只有一个是最新的。

mvcc提供了时间一致性的处理思路，在mvcc下读事务时，通常使用一个时间戳或者事务id来确定访问哪个状态的数据库及哪些版本的数据。读事务跟写事务彼此是隔离开来的，彼此之间不会影响。假设同一份数据，既有读事务访问，又有写事务操作，实际上，写事务会新建一个新的数据版本，而读事务访问的是旧的数据版本，直到写事务提交，读事务才会访问到这个新的数据版本。

mvcc有两种实现方式，第一种实现方式是将数据记录的多个版本保存在数据库中，当这些不同版本数据不再需要时，垃圾收集器回收这些记录。这个方式被postgresql和firebird/interbase采用，sql server使用的类似机制，所不同的是旧版本数据不是保存在数据库中，而保存在不同于主数据库的另外一个数据库tempdb中。第二种实现方式只在数据库保存最新版本的数据，但是会在使用undo时动态重构旧版本数据，这种方式被oracle和 mysql/innodb使用。

2、innodb的mvcc实现机制

　　mvcc可以认为是行级锁的一个变种，它可以在很多情况下避免加锁操作，因此开销更低。mvcc的实现大都都实现了非阻塞的读操作，写操作也只锁定必要的行。innodb的mvcc实现，是通过保存数据在某个时间点的快照来实现的。一个事务，不管其执行多长时间，其内部看到的数据是一致的。也就是事务在执行的过程中不会相互影响。下面我们简述一下mvcc在innodb中的实现。

　　innodb的mvcc，通过在每行记录后面保存两个隐藏的列来实现：一个保存了行的创建时间，一个保存行的过期时间（删除时间），当然，这里的时间并不是时间戳，而是系统版本号，每开始一个新的事务，系统版本号就会递增。在rr隔离级别下，mvcc的操作如下：

select操作。

innodb只查找版本早于（包含等于）当前事务版本的数据行。可以确保事务读取的行，要么是事务开始前就已存在，或者事务自身插入或修改的记录。

行的删除版本要么未定义，要么大于当前事务版本号。可以确保事务读取的行，在事务开始之前未删除。

insert操作。将新插入的行保存当前版本号为行版本号。

delete操作。将删除的行保存当前版本号为删除标识。

update操作。变为insert和delete操作的组合，insert的行保存当前版本号为行版本号，delete则保存当前版本号到原来的行作为删除标识。

　　由于旧数据并不真正的删除，所以必须对这些数据进行清理，innodb会开启一个后台线程执行清理工作，具体的规则是将删除版本号小于当前系统版本的行删除，这个过程叫做purge。

3、简单的小例子

1 2 3 4 create table yang( id int primary key auto_increment, name varchar (20)); }

　　假设系统的版本号从1开始.

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 ;

　　对应在数据中的表如下(后面两列是隐藏列,我们通过查询语句并看不到)

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 ;

　　这时表中的数据如下:

　　然后接着执行事务2中的(2),由于id=4的数据的创建时间(事务id为3),执行当前事务的id为2,而innodb只会查找事务id小于等于当前事务id的数据行,所以id=4的数据行并不会在执行事务2中的(2)被检索出来,在事务2中的两条select 语句检索出来的数据都只会下表:

　假设2

　　假设在执行这个事务id为2的过程中,刚执行到(1),假设事务执行完事务3后，接着又执行了事务4;
　　第四个事务:

1 2 3 start transaction ; delete from yang where id=1; commit ;

　　此时数据库中的表如下:

　　接着执行事务id为2的事务(2),根据select 检索条件可以知道,它会检索创建时间(创建事务的id)小于当前事务id的行和删除时间(删除事务的id)大于当前事务的行,而id=4的行上面已经说过,而id=1的行由于删除时间(删除事务的id)大于当前事务的id,所以事务2的(2)select * from yang也会把id=1的数据检索出来.所以,事务2中的两条select 语句检索出来的数据都如下: