MySQL 8 MVCC机制

MySQL 8 MVCC机制

1.MVCC机制概述

​ MVCC是数据库中的一种并发控制机制，它的全称是"Multi-Version Concurrency Control"，即多版本并发控制。MVCC机制通过在数据库中维护多个版本的数据来实现并发控制，从而保证多个并发事务之间可以读写不同版本的数据而不会发生冲突。

​ MVCC的基本思想是，对于每个事务，在执行修改操作时，不会直接修改数据库中的数据，而是先复制一份当前数据版本，然后对该版本进行修改。当其他事务需要访问该数据时，数据库会根据该事务的隔离级别，为其提供不同的数据版本。

​ MVCC只在读已提交和可重复读隔离级别实现，未提交读每次读取数据都是读最新的，而不是最正确的，串行化则是对每个事务都加锁，事务不能并发执行，这个时候不需要任何并发控制机制。

2.MVCC两大底层机制

​ 在MySQL中，MVCC的实现主要是通过两个机制来实现的：Undo Log和Read View。

​ Undo Log机制主要用于支持事务的回滚操作，即在执行修改操作时，会将修改前的数据保存在Undo Log中，以便在回滚时能够恢复数据。同时，每个事务都有自己的Undo Log，用于保存自己所做的修改操作。当其他事务需要读取数据时，MySQL会根据事务的隔离级别，将数据版本与Undo Log结合起来，为其提供一个符合其需求的数据版本。

​ Read View机制用于实现事务的隔离性。在每个事务开始时，MySQL会为其创建一个Read View，用于标识当前事务开始时的数据版本。Read View包括一个事务的ID、事务开始时间和所有已提交的事务ID。当事务需要读取数据时，MySQL会根据Read View中的信息，选择符合要求的数据版本。

3.MVCC具体实现原理

​ MVCC的实现原理是在每一条记录的后面添加两列，trx_id（事务id）和roll_pointer（指针），每次修改数据时都生成一个新版本，新版本的事务id为当前事务的id，这个id一般是时间戳，是递增的，而新版本的roll_pointer则指向上一个版本，然后将修改前的数据保存在Undo Log中。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QcVCvRrA-1680788086658)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20230404221201581.png)]

Mysql在事务开始时创建一个Read View，Read View中包含此时此刻其他开始了但未提交的事务的id，并将这些事务id进行排序。

比如这些事务的区间是[10,20]，那么10之前的肯定是已经提交了的事务。

在事务中读数据时，读取到的数据的事务id所在区间可以分为小于10、[10,20]、大于20三个区间。

其中小于10的是已提交的事务，[10,20]和大于20的都是不确定是否提交的，就当他没提交。

这个时候进行比较，如果读取到的数据的事务id小于10，则该数据是已提交的，可以读，如果是大于10的，则是没提交的，不可以直接读，需要往前找，直到找到一个可以读的版本（没找到就不可读），然后读取。

4.MVCC对于已提交读和可重复读实现上的区别

​ Mysql在事务开始时肯定会创建一个Read View，但是两者区别在于：

​ 已提交读每次读取数据时，都会新建一个Read View，然后根据这个Read View按照之前的比较办法读取已提交版本的数据，但是存在的问题就是一个事务中，多次读取相同数据时，由于Read View不同，所以已提交读的区间就会不一样，比如之前的例子，事务创建时Read View可读区间是小于10，但是再读的时候这个区间就可能是小于15，然后读出来的数据一个是小于10的版本，一个是小于15的版本，就有可能不一样，造成不可重复读的问题。

​ 可重复读每次读取数据时，不会新建一个Read View，都是沿用事务开始时创建的Read View，所以可读区间是完全一致的，读到的数据也是一样的，所以实现了可重复读。

5.Mysql事务默认隔离级别为什么是可重复读？

以实现了可重复读。

5.Mysql事务默认隔离级别为什么是可重复读？

​ 根据之前的介绍我们得知，已提交读每次读取数据时，都会新建一个Read View，可重复读每次读取数据时，不会新建一个Read View，都是沿用事务开始时创建的Read View，所以可重复读效率比较高，而且隔离级别更高，所以Mysql事务默认隔离级别是可重复读。