文档参考：
第16章_多版本并发控制.pdf · 资料文件 · 语雀

1 概述

前提概述
事务有4种特性：原子性、一致性、隔离性和持久性。那么事务的四种特性到底是基于什么机制实现的？

  • 事务的隔离性由锁机制+MVCC来实现。
    • 锁机制：用于写写隔离、读写隔离。在数据库中，除传统的计算资源（CPU、内存、I/O等）的争用外，数据也是一种供多用户共享的资源。为保证数据的一致性，需要对并发操作进行控制 ，因此产生了锁 。同时锁机制也为实现MySQL的各个隔离级别提供了保证。
    • MVCC：用于读写隔离。
  • 事务的原子性、一致性、持久性由事务的redo日志和undo日志来保证。

什么是MVCC
MVCC （Multiversion Concurrency Control），多版本并发控制。顾名思义，MVCC 是通过数据行的多个版本管理来实现数据库的并发控制 。这项技术使得在InnoDB的事务隔离级别下执行一致性读操作有了保证。换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值，这样在做查询的时候就不用等待另一个事务释放锁。
MVCC没有正式的标准，在不同的DBMS中MVCC的实现方式可能是不同的，也不是普遍使用的。这里讲解的是InnoDB中MVCC的实现机制（MySQL其它的存储引擎并不支持它）。
MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突。而读操作分为如下两种方式：快照读、当前读。

  • 快照读：即使有读写冲突时，也能做到不加锁，非阻塞并发读取数据。快照读又叫一致性读，读取的是快照数据，所以可能读到的不是最新版本的数据而是历史版本的。
    • 不加锁的简单的SELECT读都属于快照读，即不加锁的非阻塞读，如select * from users;//快照读,不加锁。
    • 快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读。
  • 当前读：当前读读取的是记录的最新版本（最新数据，而不是历史版本的数据），读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。
    • 加锁的 SELECT属于当前读。
      • SELECT * FROM student LOCK IN SHARE MODE;//共享锁。
      • SELECT * FROM student FOR UPDATE;//排他锁
    • 对数据进行增删改都会进行当前读
      • INSERT INTO student values(1,2);//排他锁
      • DELETE FROM student WHERE id=2;//排他锁
      • UPDATE student SET name='xx' where id=2;//排他锁

MVCC的作用体现
mvcc使得mysql在innodb存储引擎事务的隔离级别为RR（可重复读阶段）就解决了幻读的问题。
image.png
几句话小总结
这里介绍了MVCC在READ COMMITTD 、 REPEATABLE READ这两种隔离级别的事务在执行快照读操作时访问记录的版本链的过程。这样使不同事务的读-写 、写-读操作并发执行，从而提升系统性能。
核心点在于ReadView的原理， READ COMMITTD、REPEATABLE READ这两个隔离级别的一个很大不同，就是生成ReadView的时机：

  • READ COMMITTD 在每一次进行普通SELECT操作前都会生成一个ReadView。故其不能解决不可重复读和幻读。
  • REPEATABLE READ 只在第一次进行普通SELECT操作前生成一个ReadView，之后的查询操作都重复使用这个ReadView就好了。故其能解决不可重复读和幻读。

通过MVCC我们可以解决：

  • 读写之间阻塞的问题。通过MVCC可以让读写互相不阻塞，即读不阻塞写，写不阻塞读，这样就可以提升事务并发处理能力。
  • 降低了死锁的概率。这是因为MVCC采用了乐观锁的方式，读取数据时并不需要加锁，对于写操作，也只锁定必要的行。

  • 解决快照读的问题。当我们查询数据库在某个时间点的快照时，只能看到这个时间点之前事务提交更新的结果，而不能看到这个时间点之后事务提交的更新结果。

    2 MVCC原理

    mvcc由隐藏字段、undo log版本链、readview来实现。

    隐藏字段

    对于使用 InnoDB 存储引擎的表来说，它的聚簇索引记录中都包含两个必要的隐藏字段。

  • trx_id ：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的事务id赋值给trx_id隐藏列。

    • 扩展：事务ID是如何产生的？事务在执行过程中，只有在第一次真正修改记录时(比如使用INSERT、DELETE、UPDATE语句)，才会被分配一个单独的事务id，这个事务id是递增的。
  • roll_pointer ：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到 undo日志中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。note：insert undo只在事务回滚时起作用，当事务提交后，该类型的undo日志就没用了，它占用的Undo Log Segment也会被系统回收（也就是该undo日志占用的Undo页面链表要么被重用，要么被释放）。

    undo log版本链

    每次对数据记录做更新后，都会将旧值放到一条 undo日志中，就算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被 roll_pointer 属性连接成一个链表，我们把这个链表称之为版本链 ，版本链的头节点就是当前记录最新的值。每个版本中还包含生成该版本时对应的事务id 。

    案例：两个事务分别对表student做更新操作。每次对记录进行改动，都会记录一条undo日志，每条undo日志也都有一个 roll_pointer 属性（ INSERT 操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些 undo日志都连起来，串成一个链表。 image.png

ReadView

概念
在MVCC机制中，多个事务对同一个行记录进行更新会产生多个历史快照，这些历史快照保存在Undo Log里。如果一个事务想要查询这个行记录，需要读取哪个版本的行记录呢？这时就需要用到ReadView了，它帮我们解决了行的可见性问题。
ReadView就是事务在使用MVCC机制进行快照读操作时产生的读视图，如事务A要访问某个表，在该事务启动时，就会为这个事务生成一个读视图快照。这个读视图快照里面记录并维护了系统当前活跃事务的ID(“活跃”指的就是事务启动了但还没提交)。
核心一句话：ReadView和事务是一对一的，如start transaction; select * from users;//开启了事务，事务里面查询，那么就会在该事务里面绑定一个ReadView。
设计思想

  • 使用READ UNCOMMITTED隔离级别的事务，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了。
  • 使用SERIALIZABLE隔离级别的事务，InnoDB规定使用加锁的方式来访问记录。
  • 使用READ COMMITTED 和REPEATABLE READ隔离级别的事务，都必须保证读到已经提交了的事务修改过的记录。假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的，核心问题就是需要判断一下版本链中的哪个版本是当前事务可见的，这是ReadView要解决的主要问题。

ReadView的内容
ReadView中主要包含4个比较重要的内容，分别如下：

  • creator_trx_id ，创建这个 Read View 的事务 ID。说明：只有在对表中的记录做改动时（执行INSERT、DELETE、UPDATE这些语句时）才会为事务分配事务id，否则在一个只读事务中的事务id值都默认为0。
  • trx_ids ，表示在生成ReadView时当前系统中活跃的读写事务(活跃指的就是事务启动了但还没提交)的事务id列表 。
  • up_limit_id ，活跃的事务中最小的事务 ID。
  • low_limit_id ，表示生成ReadView时系统中应该分配给下一个事务的 id 值。low_limit_id 是系统最大的事务id值，这里要注意是系统中的事务id，需要区别于正在活跃的事务ID。

举例：事务开启查询的时候，会生成trx_ids集合，发现当前系统还活跃的事务为trk2、trx3、trx5、trx8。则此时系统的最大事务ID (low_limit_id)为trx8+1，活跃的最小事务ID (up_limit_id)为trx2。
image.png
ReadView的规则
有了这个ReadView，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见。
注意：trx_id是递增依次分配的（核心就是版本号功能，在执行查询的时候，记录下系统里面已经提交的版本号和正在工作的版本号。即乐观锁功能）。

  1. 如果被访问版本的trx_id属性值与ReadView中的creator_trx_id值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。
  2. 如果被访问版本的trx_id属性值小于ReadView中的 up_limit_id 值，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本可以被当前事务访问。
  3. 如果被访问版本的trx_id属性值大于或等于ReadView中的low_limit_id值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。
  4. 如果被访问版本的trx_id属性值在ReadView的up_limit_id和low_limit_id 之间，那就需要判断一下trx_id属性值是不是在 trx_ids 列表中。
    • 如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问。
    • 如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。

image.png
MVCC整体操作流程
我们来看下当查询一条记录的时候，系统如何通过MVCC找到它

通用流程

  1. 首先获取事务自己的版本号，也就是事务 ID；
  2. 获取ReadView；
    1. 当隔离级别为读已提交（RC）时：一个事务中的每一次 SELECT 查询都会重新获取一次Read View，所以可能会产生不可重复读或者幻读的情况。
    2. 当隔离级别为可重复读（RR）时：一个事务只在第一次 SELECT 的时候会获取一次 Read View，而后面所有的 SELECT 都会复用这个 Read View。所以就避免了不可重复读和幻读。

image.png

  1. 查询得到的数据，然后与 ReadView 中的事务版本号进行比较；
  2. 如果不符合 ReadView 规则，就需要从 Undo Log 中获取历史快照；

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

    4 举例说明

    详见顶部文档说明
    背景
    image.png
    READ COMMITTED隔离级别下

  4. 现在有两个事务id分别为10 、 20的事务在执行

image.png

  1. 新的事务开始SELECT（假设事务ID为21）

image.png

  1. 之前的10事务开始提交，20事务做更新但是没有提交

image.png

  1. 事务ID21的执行SELECT

image.png