【面试题 - mysql】进阶篇 - MVCC多版本并发控制原理
MVCC多版本并发控制
- 前言
- 1. 基本概念
-
- 什么是MVCC
-
- 数据库并发有以下几种场景：
- 回顾事务的特性
- 回顾事务的隔离级别
- 1.1 当前读
- 1.2 快照读
- 2. MVCC（多版本并发控制）
-
- 2.1 隐藏字段（DB_TRX_ID / DB_ROLL_PTR / DB_ROW_ID）
- 2.2 undo log (回滚日志)
-
- 2.2.1 版本链
- 2.3 readView
- 3. 原理分析
-
- 3.1 RC 隔离级别
- 3.2 RR 隔离级别
- 5. 幻读问题
前言
在并发读写数据库时，读操作可能会不一致的数据（脏读）。为了避免这种情况，需要实现数据库的并发访问控制，最简单的方式就是加锁访问。由于，加锁会将读写操作串行化，所以不会出现不一致的状态。但是，读操作会被写操作阻塞，大幅降低读性能。在java concurrent包中，有copyonwrite系列的类，专门用于优化读远大于写的情况。而其优化的手段就是，在进行写操作时，将数据copy一份，不会影响原有数据，然后进行修改，修改完成后原子替换掉旧的数据，而读操作只会读取原有数据。通过这种方式实现写操作不会阻塞读操作，从而优化读效率。而写操作之间是要互斥的，并且每次写操作都会有一次copy，所以只适合读大于写的情况。
MVCC为数据库解决以下两个问题：
- 并发读写数据库的时候，可以做到读操作不会阻塞写操作，写操作不会阻塞读操作，提高了并发读写性能；
- 解决脏读，不可重复读，幻读等事务隔离问题，但是不能解决更新丢失问题
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