一、MVCC简单介绍

MVCC 全称 Multi-Version Concurrency Control 即 多版本并发控制，主要是为了提高数据库的 并发性能，其基本思想是为每次事务生成一个新版本的数据，在读数据时选择不同版本的数据即可以实现对事务结果的完整性读取。MVCC 只对 InnoDB 有效，因为 myIsam不支持事务。
同一行数据平时发生读写请求时，会上锁阻塞住，但mvcc用更好的方式去处理读—写请求，做到在发生读—写请求冲突时不用加锁。这个读是指的快照读，而不是当前读，当前读是一种加锁操作，是悲观锁。

想想，读快照，是不是类似于 CopyOnWriteArrayList

二、当前读和快照读

当前读和快照读只在 InnoDB 下有。

1、当前读

https://baijiahao.baidu.com/s?id=1684889579590305541&wfr=spider&for=pc

它读取的数据库记录，都是当前最新的版本，会对当前读取的数据进行加锁，防止其他事务修改数据。是悲观锁的一种操作。
如下操作都是当前读：

  • select lock in share mode (共享锁)
  • select for update (排他锁)
  • update 。。。 where xx=… (排他锁)
  • insert (排他锁)
  • delete 。。。 where xx=…(排他锁)

  • 串行化事务隔离级别

    2、快照读

    快照读的实现是基于多版本并发控制，即 MVCC，既然是多版本，那么快照读读到的数据不一定是当前最新的数据，有可能是之前历史版本的数据。
    如下操作是快照读：

  • 不加锁的 select 操作（注：事务级别不是串行化）

快照读和 MVCC 的关系：
MVCC 是“维持一个数据的多个版本，使读写操作没有冲突”的一个抽象概念。这个概念需要具体功能去实现，这个具体实现就是快照读。

三、MVCC 解决哪些问题

1、数据库并发场景

  • 读-读：不存在任何问题，也不需要并发控制
  • 读-写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读
  • 写-写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失

    什么是 脏读、幻读、不可重复读 ？ 传送门：走嘞~

    • 第一类更新丢失：
      • 撤销一个事务的时候，把其它事务已提交的更新数据覆盖了。这是完全没有事务隔离级别造成的。如果事务1被提交，另一个事务被撤销，那么会连同事务1所做的更新也被撤销。
    • 第二类更新丢失：
      • 最后一个事务对记录所做的更改将覆盖其它事务之前对该记录所做的更改。

2、解决并发的什么问题

MVCC 用来解决读—写冲突的无锁并发控制，就是为事务分配单向增长的时间戳。为每个数据修改保存一个版本，版本与事务时间戳相关联。

解决问题如下：

  • 并发读-写时：可以做到读操作不阻塞写操作，同时写操作也不会阻塞读操作。
  • 解决脏读、幻读、不可重复读等事务隔离问题，但不能解决上面的写-写 更新丢失问题。

通过组合拳解决写写并发问题：

  • MVCC + 悲观锁：MVCC解决读写冲突，悲观锁解决写写冲突。
  • MVCC + 乐观锁：MVCC解决读写冲突，乐观锁解决写写冲突。

四、MVCC 实现原理

它的实现原理主要是版本链，undo日志 ，Read View来实现的

1、版本链

我们数据库中的每行数据，除了我们肉眼看见的数据，还有几个隐藏字段，分别是db_trx_id、db_roll_pointer、db_row_id。

  • db_trx_id：6byte，最近修改(修改/插入)事务ID：记录创建这条记录/最后一次修改该记录的事务ID。
  • db_roll_pointer（版本链关键）：7byte，回滚指针，指向这条记录的上一个版本（存储于rollback segment里）
  • db_row_id：6byte，隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB 会自动以 db_row_id产生一个聚簇索引。
  • 实际还有一个删除 flag 隐藏字段, 记录被更新或删除并不代表真的删除，而是删除 flag 值变了。

image.png
如上图，db_row_id 是数据库默认为该行记录生成的唯一隐式主键，db_trx_id 是当前操作该记录的事务ID，而 db_roll_pointer 是一个回滚指针，用于配合 undo 日志，指向上一个旧版本。
每次对数据库记录进行改动，都会记录一条 undo日志，每条 undo 日志也都有一个 roll_pointer 属性（INSERT操作对应的 undo 日志没有该属性，因为该记录并没有更早的版本），可以将这些undo日志都连起来，串成一个链表，所以现在的情况就像下图一样：
image.png
对该记录每次更新后，都会将旧值放到一条undo日志中，就算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被 roll_pointer 属性连接成一个链表，我们把这个链表称之为版本链，版本链的头节点就是当前记录最新的值。另外，每个版本中还包含生成该版本时对应的事务id，这个信息很重要，在根据ReadView 判断版本可见性的时候会用到。

2、undo 日志

Undo log 主要用于记录数据被修改之前的日志，在表信息修改之前先会把数据拷贝到undo log里。 当事务进行回滚时可以通过undo log 里的日志进行数据还原。

2.1 undo 日志用途

  • 保证事务进行 rollback 时的原子性和一致性，当事务进行回滚的时候可以用 undo log 的数据进行恢复。

  • 用于 MVCC 快照读的数据，在MVCC多版本控制中，通过读取 undo log 的历史版本数据可以实现不同事务版本号都拥有自己独立的快照数据版本。

    2.2 undo 日志种类

  • insert undo log

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

  • update undo log（主要）

    • 事务在进行 update 或 delete 时产生的 undo log ; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除。

      3、Read View（读视图）

      3.1 简单介绍

      事务进行快照读操作的时候生产的读视图(Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照。
      记录并维护系统当前活跃事务的ID (没有commit，当每个事务开启时，都会被分配一个ID, 这个ID是递增的，所以越新的事务，ID值越大)，是系统中当前不应该被本事务看到的其他事务id列表。
      Read View 主要是用来做可见性判断的, 即当我们某个事务执行快照读的时候，对该记录创建一个Read View读视图，把它比作条件用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的undo log里面的某个版本的数据。

      3.2 ReadView的属性

  • trx_ids: 当前系统活跃(未提交)事务版本号集合。

  • max_limit_id: 创建当前read view 时“当前系统最大事务版本号+1”。
  • min_limit_id: 创建当前read view 时“系统正处于活跃事务最小版本号”
  • creator_trx_id: 创建当前read view的事务版本号；

    4、事务可见性判断流程（重要）

    有了这个 ReadView，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见：
    记 当前被访问的版本的事务Id 是 db_trx_id
  1. db_trx_id < min_limit_id || db_trx_id == creator_trx_id（显示）

如果数据事务ID小于read view中的最小活跃事务ID，则可以肯定该数据是在当前事务启动之前就已经存在了的,所以可以显示。
或者数据的事务ID等于 creator_trx_id ，那么说明这个数据就是当前事务自己生成的，自己生成的数据自己当然能看见，所以这种情况下此数据也是可以显示的。

  1. db_trx_id >= max_limit_id（不显示）

如果数据事务ID大于read view 中的当前系统的最大事务ID，则说明该数据是在当前read view 创建之后才产生的，所以数据不显示。如果小于则进入下一个判断。

  1. db_trx_id 是否在活跃事务（trx_ids）中
    • 不存在：则说明 read view 产生的时候事务已经 commit 了，这种情况数据则可以显示。
    • 已存在：则代表我Read View生成时刻，你这个事务还在活跃，还没有Commit，你修改的数据，我当前事务也是看不见的。


  1. 如果某个版本的数据对当前事务不可见的话，那就顺着版本链找到下一个版本的数据，继续按照上边的步骤判断可见性，依此类推，直到版本链中的最后一个版本。如果最后一个版本也不可见的话，那么就意味着该条记录对该事务完全不可见，查询结果就不包含该记录。

    五、MVCC 和 事务隔离级别的关系

    上面所讲的Read View用于支持RC（Read Committed，读提交）和RR（Repeatable Read，可重复读）隔离级别的实现。

1、readView 在 RC 和 RR 生成的时机

  • RC隔离级别下，是每个快照读都会生成并获取最新的Read View；

  • 而在RR隔离级别下，则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View，之后的查询就不会重复生成了，所以一个事务的查询结果每次都是一样的。

    2、解决幻读问题

    幻读：https://www.yuque.com/wangchao-volk4/whmpo0/onuimk#PyzAR

  • 快照读：通过MVCC来进行控制的，不用加锁。按照MVCC中规定的“语法”进行增删改查等操作，以避免幻读。

  • 当前读：仅仅靠MVC是无法解决的，必须依靠 通过MVCC+next-key锁（行锁+gap锁）来解决问题的，即 串行化

    • next-key locks由record locks(索引加锁) 和 gap locks(间隙锁，每次锁住的不光是需要使用的数据，还会锁住这些数据附近的数据)

      3、RC、RR级别下的InnoDB快照读区别

  • 在RR级别下的某个事务的对某条记录的第一次快照读会创建一个快照及Read View， 将当前系统活跃的其他事务记录起来，此后在调用快照读的时候，还是使用的是同一个Read View，所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个Read View，所以对之后的修改不可见；

  • 即RR级别下，快照读生成Read View时，Read View会记录此时所有其他活动事务的快照(回忆)，这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见
  • 而在RC级别下的，事务中，每次快照读都会新生成一个快照和Read View, 这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因。

    六、总结

    综上所述，MVCC 在隔离级别为 READ COMMITTED、REPEATABLE READ 中用到，事务在执行 快照读（普通的SELECT）时 访问 版本链 的过程，这样子可以使不同的事务的 读写、写读 操作并发执行，从而提高系统的性能。

    为什么 Read Uncommitted 不用 MVCC？因为 读未提交，就是要读取没有提交的数据，不存在数据隔离，随便读的，而 MVCC 是一种高效的实现方式来解决高并发读写情况下的数据隔离的问题。 为什么 SERIALIZABLE 不用 MVCC？MVCC无法解决当前读的幻读问题。而串行化利用了 行锁+间隙锁。可以回顾 https://www.yuque.com/wangchao-volk4/whmpo0/stcrk1#ZihqX

七、感谢

https://www.cnblogs.com/jmliao/p/13204946.html
https://www.cnblogs.com/boluopabo/p/13111961.html
https://mp.weixin.qq.com/s/oOL4yradD5w73VsrfoyneA