什么是MVCC？

MVCC，全称Multi-Version Concurrency Control，即多版本并发控制。MVCC是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。

MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读。

什么是当前读和快照读？

在学习MVCC多版本并发控制之前，我们必须先了解一下，什么是MySQL InnoDB下的当前读和快照读?

当前读

​ 像select 语句 lock in share mode(共享锁), select 语句 for update ;

​ update, insert ,delete(排他锁)这些操作都是一种当前读，为什么叫当前读？就是它读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。

快照读

​ 像不加锁的select * from xxx 操作就是快照读，即不加锁的非阻塞读，不涉及其他锁之间的冲突；快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读；之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，即MVCC,可以认为MVCC是行锁的一个变种，但它在很多情况下，避免了加锁操作，降低了开销；既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。

​ 说白了MVCC就是为了实现读(select)-写冲突不加锁，而这个读指的就是快照读, 而非当前读，当前读实际上是一种加锁的操作，是悲观锁的实现。

当前读，快照读和MVCC的关系

准确的说，MVCC多版本并发控制指的是 “维持一个数据的多个版本，使得读写操作没有冲突” 这么一个概念。仅仅是一个理想概念。

而在MySQL中，实现这么一个MVCC理想概念，我们就需要MySQL提供具体的功能去实现它，而快照读就是MySQL为我们实现MVCC理想模型的其中一个具体非阻塞读功能。而相对而言，当前读就是悲观锁的具体功能实现。

要说的再细致一些，快照读本身也是一个抽象概念，再深入研究。MVCC模型在MySQL中的具体实现则是由 3个隐式字段，undo日志 ，Read View 等去完成的，具体可以看下面的MVCC实现原理：

MVCC能解决什么问题，好处是？

​ 数据库并发场景有三种，分别为：

  • 读-读：不存在任何问题，也不需要并发控制。

  • 读-写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读。

  • 写-写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失。

MVCC只能针对第二种读-写冲突进行处理， mvcc只能去解决脏读、不可重复读问题，不能解决幻读的问题；

多版本并发控制（MVCC）是一种用来解决读-写冲突的无锁并发控制，也就是为事务分配单向增长的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，读操作只读该事务开始前的数据库的快照。

所以MVCC可以为数据库解决以下问题：

​ 在并发读写数据库时，可以做到在读(select)操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能。

​ 同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题。

MVCC带来的好处是？

​ 总之，MVCC就是因为大牛们，不满意只让数据库采用悲观锁这样性能不佳的形式去解决读-写冲突问题，而提出的解决方案，所以在数据库中，因为有MVCC，所以我们可以形成两个组合：

  • MVCC + 悲观锁

    ​ MVCC解决读写冲突，悲观锁解决写写冲突

  • MVCC + 乐观锁

    ​ MVCC解决读写冲突，乐观锁解决写写冲突

​ 这种组合的方式就可以最大程度的提高数据库并发性能，并解决读写冲突，和写写冲突导致的问题。

MVCC实现原理

MVCC的目的就是多版本并发控制，在数据库中的实现，就是为了解决读写冲突，它的实现原理主要是依赖记录中的 3个隐藏字段，undo日志 ，Read View 来实现的。

三个隐藏字段

首先需要知道的是，在MySQL中，会默认为我们的表后面添加三个隐藏字段：

  • DB_TRX_ID：事务ID，6 byte, 最近修改(修改/插入)事务ID，记录创建这条记录/最后一次修改该记录的事务ID，或者说记录的是当前事务在做INSERT或UPDATE语句操作时的事务ID（DELETE语句被当做是UPDATE语句的特殊情况，后面会进行说明)；
  • DB_ROLL_PTR：回滚指针，7 byte, 通过它可以将不同的版本串联起来，形成版本链。相当于链表的next指针。
  • DB_ROW_ID：6 byte，隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB会自动以DB_ROW_ID产生一个聚簇索引。

undo log

undo日志保证了事务的原子性和实现MVCC，undo log日志主要分为两种：

  • insert undo log

    代表事务在insert新记录时产生的undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃；

  • update undo log

    事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要，在快照读(select，当读的过程中有写的十事务开始和提交，会造成读数据的脏读、不可重复读、幻读等)时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除。

purge

Mysql有对应的回收机制，purge线程，当快照读或者事务回滚不需要涉及读日志，就会被统一删除；

从前面的分析可以看出，为了实现InnoDB的MVCC机制，更新或者删除操作都只是设置一下老记录的deleted_bit，并不真正将过时的记录删除。

为了节省磁盘空间，InnoDB有专门的purge线程来清理deleted_bit为true的记录。为了不影响MVCC的正常工作，purge线程自己也维护了一个read view（这个read view相当于系统中最老活跃事务的read view）;如果某个记录的deleted_bit为true，并且DB_TRX_ID相对于purge线程的read view可见，那么这条记录一定是可以被安全清除的。

对MVCC有帮助的实质是update undo log ，undo log实际上就是存在rollback segment中旧记录链。

版本链

所有版本的数据都只会存一份，然后通过回滚指针连接起来，之后就是通过一定的规则找到具体是哪个版本上的数据就行了。假设现在有一张account表，其中有id和name两个字段，那么版本链的示意图如下：

而具体版本链的比对规则如下，首先从版本链中拿出最上面第一个版本的事务ID开始逐个往下进行比对：

（其中min_id指向ReadView中未提交事务数组中的最小事务ID，而max_id指向ReadView中的已经创建的最大事务ID）

  • 如果落在绿色区间（DB_TRX_ID < min_id）：这个版本比min_id还小（事务ID是从小往大顺序生成的），说明这个版本在SELECT之前就已经提交了，所以这个数据是可见的。或者（这里是短路或，前面条件不满足才会判断后面这个条件）这个版本的事务本身就是当前SELECT语句所在事务的话，也是一样可见的；

  • 如果落在红色区间（DB_TRX_ID > max_id）：表示这个版本是由将来启动的事务来生成的，当前还未开始，那么是不可见的；

  • 如果落在黄色区间（min_id <= DB_TRX_ID <= max_id）：这个时候就需要再判断两种情况：

    • 如果这个版本的事务ID在ReadView的未提交事务数组中，表示这个版本是由还未提交的事务生成的，那么就是不可见的；
    • 如果这个版本的事务ID不在ReadView的未提交事务数组中，表示这个版本是已经提交了的事务生成的，那么是可见的。

    如果在上述的判断中发现当前版本是不可见的，那么就继续从版本链中通过回滚指针拿取下一个版本来进行上述的判断。

我们就可以看出，不同事务或者相同事务的对同一记录的修改，会导致该记录的undo log成为一条记录版本线性表，即是事务链，undo log的链首就是最新的旧记录，链尾就是最早的旧记录。

ReadView

读视图，进行不同版本的可见性分析，事务快照读时候会生成。

说白了Read View就是事务进行快照读(select * from)操作的时候生产的读视图(Read View)，在该事务执行的快照读的那一刻，会生成事务系统当前的一个快照，记录并维护系统当前活跃事务(未提交事务)的ID(当每个事务开启时，都会被分配一个ID, 这个ID是递增的，所以最新的事务，ID值越大)。

所以我们知道 Read View主要是用来做可见性判断的, 即当我们某个事务执行快照读的时候，对该记录创建一个Read View读视图，把它比作条件用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的undo log里面的某个版本的数据。

ReadView中主要包含4个比较重要的内容：

read view中活跃就是指未提交的事务

  • m_ids：表示在生成ReadView时当前系统中活跃的读写事务的事务id列表。

  • min_trx_id：表示在生成ReadView时当前系统中活跃的读写事务中最小的事务id，也就是m_ids中的最小值。

  • max_trx_id：表示生成ReadView时系统中应该分配给下一个事务的id值。

  • creator_trx_id：表示生成该ReadView的快照读操作产生的事务id。

注意max_trx_id并不是m_ids中的最大值，事务id是递增分配的。比方说现在有id为1， 2， 3这三个事务，之后id为3的事务提交了。那么一个新的读事务在生成ReadView时， m_ids就包括1和2， min_trx_id的值就是1，max_trx_id的值就是4。

基于RR可重复读隔离级别，实现的基本原理

​ 在select读数据的过程中，m_ids首次发现未提交的事务信息不会因在查找过程中其他事务id提交而把该事务id排除在外，直至查询到该事务链中最后提交的事务

读已提交的隔离级别

​ m_ids:保存事务系统中的活跃的事务id，基于m_ids中的id信息在事务链中直到查找到非活跃的事务id(已提交的事务，不管事务提交是否在read view生成后)，此时就认为是该事务id查询的信息

​ ==RC隔离级别是在执行sql时生成read view，RR隔离级别是在事务开始生成read view。==

有了这个ReadView，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见：

1）如果被访问版本的trx_id属性值与ReadView中的creator_trx_id值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。

2）如果被访问版本的trx_id属性值小于ReadView中的min_trx_id值，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本可以被当前事务访问。

​ 3）如果被访问版本的trx_id属性值大于ReadView中的max_trx_id值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。

​ 4）如果被访问版本的trx_id属性值在ReadView的min_trx_id和max_trx_id之间，那就需要判断一下trx_id属性值是不是在m_ids列表中，如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问；如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版 本可以被访问。

参考资料

https://blog.csdn.net/SnailMann/article/details/94724197

https://blog.csdn.net/weixin_30342639/article/details/107552255

https://zhuanlan.zhihu.com/p/360335322