【面试题 - mysql】进阶篇 - MVCC多版本并发控制原理

前言

在并发读写数据库时，读操作可能会不一致的数据（脏读）。为了避免这种情况，需要实现数据库的并发访问控制，最简单的方式就是加锁访问。由于，加锁会将读写操作串行化，所以不会出现不一致的状态。但是，读操作会被写操作阻塞，大幅降低读性能。在java concurrent包中，有copyonwrite系列的类，专门用于优化读远大于写的情况。而其优化的手段就是，在进行写操作时，将数据copy一份，不会影响原有数据，然后进行修改，修改完成后原子替换掉旧的数据，而读操作只会读取原有数据。通过这种方式实现写操作不会阻塞读操作，从而优化读效率。而写操作之间是要互斥的，并且每次写操作都会有一次copy，所以只适合读大于写的情况。

MVCC为数据库解决以下两个问题：

1. 并发读写数据库的时候，可以做到读操作不会阻塞写操作，写操作不会阻塞读操作，提高了并发读写性能；
2. 解决脏读，不可重复读，幻读等事务隔离问题，但是不能解决更新丢失问题

1. 基本概念

什么是MVCC

mvcc，也就是多版本并发控制，是为了在读取数据时不加锁来提高读取效率和并发性的一种手段。

数据库并发有以下几种场景：

读-读：不存在任何问题。
读-写：有线程安全问题，可能出现脏读、幻读、不可重复读。
写-写：有线程安全问题，可能存在更新丢失等。

mvcc解决的就是读写时的线程安全问题，线程不用去争抢读写锁。
mvcc所提到的读是快照读，也就是普通的select语句。快照读在读写时不用加锁，不过可能会读到历史数据。

回顾事务的特性

原子性：通过undolog实现。
持久性：通过redolog实现。
隔离性：通过加锁（当前读），MVCC（快照读）实现。
一致性：通过undolog、redolog、隔离性共同实现。

回顾事务的隔离级别

读未提交：允许读取尚未提交的数据变更。可能会导致脏读、幻读或不可重复读。
读已提交：允许读取已经提交的数据。可能会导致幻读和不可重复读，避免脏读。
可重复读：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改。可能会导致幻读，避免脏读和，可重复读。
可串行化：最高隔离级别，避免脏读，不可重复读，幻读。

1.1 当前读

读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如：select … lock in share mode(共享锁)，select …for update、update、insert、delete(排他锁)都是一种当前读。

1.2 快照读

简单的select（不加锁）就是快照读，快照读，读取的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读。

• Read Committed：每个快照读都会生成并获取最新的readview。
• Repeatable Read：只有在同一个事务的第一个快照读才会创建readview，之后的每次快照读都使用的同一个readview，所以每次的查询结果都是一样的。

默认隔离级别RR下自测

在测试中,我们看到即使事务B提交了数据,事务A中也查询不到。 原因就是因为普通的select是快照读，而在当前默认的RR隔离级别下，开启事务后第一个select语句才是快照读的地方，后面执行相同的select语句都是从快照中获取数据，可能不是当前的最新数据，这样也就保证了可重复读。

2. MVCC（多版本并发控制）

指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView。

2.1 隐藏字段（DB_TRX_ID / DB_ROLL_PTR / DB_ROW_ID）

创建表的时候，InnoDB还会自动的给我们添加三个隐藏字段及其含义分别是：

而上述的前两个字段是肯定会添加的， 是否添加最后一个字段DB_ROW_ID，得看当前表有没有主键，如果有主键，则不会添加该隐藏字段。

2.2 undo log (回滚日志)

2.2.1 版本链

有一张表原始数据为：

然后，有四个并发事务同时在访问这张表。
A. 第一步


B. 第二步

C. 第三步

最终我们发现，不同事务或相同事务对同一条记录进行修改，会导致该记录的undolog生成一条记录版本链表，链表的头部是最新的旧记录，链表尾部是最早的旧记录。

2.3 readView

ReadView（读视图）是 快照读 SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）id。
ReadView中包含了四个核心字段：

而在readview中就规定了版本链数据的访问规则：trx_id 代表当前undolog版本链对应事务ID。

不同的隔离级别，生成ReadView的时机不同：
READ COMMITTED ：在事务中每一次执行快照读时生成ReadView。
REPEATABLE READ：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。

3. 原理分析

3.1 RC 隔离级别

RC隔离级别下，在事务中每一次执行快照读时生成ReadView。

在事务5中，查询了两次id为30的记录，由于隔离级别为Read Committed，所以每一次进行快照读都会生成一个ReadView，那么两次生成的ReadView如下。

那么这两次快照读在获取数据时，就需要根据所生成的ReadView以及ReadView的版本链访问规则，到undolog版本链中匹配数据，最终决定此次快照读返回的数据。
A. 先来看第一次快照读具体的读取过程：

在进行匹配时，会从undo log的版本链，从上到下进行挨个匹配：
先匹配这条记录，这条记录对应的trx_id为4，也就是将4带入右侧的匹配规则中。 ①不满足 ②不满足 ③不满足 ④也不满足 ，都不满足，则继续匹配undo log版本链的下一条。

再匹配第二条 ，这条记录对应的trx_id为3，也就是将3带入右侧的匹配规则中。①不满足 ②满足 。终止匹配，此次快照读，返回的数据就是版本链中记录的这条数据。

3.2 RR 隔离级别

RR隔离级别下，仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。 而RR 是可重复读，在一个事务中，执行两次相同的select语句，查询到的结果是一样的。

MVCC的实现原理就是通过 InnoDB表的隐藏字段、UndoLog 版本链、ReadView来实现的。而MVCC + 锁，则实现了事务的隔离性。 而一致性则是由redolog 与 undolog保证。

5. 幻读问题

快照读：通过mvcc，RR的隔离级别解决了幻读问题，因为每次使用的都是同一个readview。
当前读：通过next-key锁（行锁+gap锁），RR隔离级别并不能解决幻读问题。

视频链接：https://www.bilibili.com/video/BV1Kr4y1i7ru?p=144&vd_source=b901ef0e9ed712b24882863596eab0ca
什么是MVCC：https://huaweicloud.csdn.net/63354fc7d3efff3090b53e5e.html?spm=1001.2101.3001.6650.6&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Eactivity-6-124232192-blog-18093187.pc_relevant_recovery_v2&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Eactivity-6-124232192-blog-18093187.pc_relevant_recovery_v2&utm_relevant_index=13
前言：https://blog.csdn.net/chosen0ne/article/details/18093187