MVCC学习圣经：一文穿透MySQL MVCC，吊打面试官

尼恩说在前面

在40岁老架构师 尼恩的读者交流群(50+)中，很多小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试机会，遇到很多很重要的面试题：

1.请解释Mysql MVCC，它的 作用是什么？

2.在MySQL中，MVCC是如何实现的？请简述其工作原理。

3.MVCC是如何解决读-写和写-写冲突的？

4.在并发环境中，当多个事务同时读取同一行数据时，MVCC是如何保证每个事务看到的数据版本是一致的？

5.MVCC如何帮助提高数据库的并发性能？

最近有小伙伴在面试阿里，又遇到了MVCC相关的面试题。小伙伴 支支吾吾的说了几句，没说清楚，面试挂了。

所以，尼恩给大家做一下系统化、体系化的梳理，使得大家内力猛增，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。

这里，尼恩团队把MVCC 进行了全面的梳理，穿透式的梳理，

梳理为一个PDF文档 《MVCC 学习圣经：一次穿透MYSQL MVCC 》， 并且持续迭代。

这个文档将成为大家 面试的杀手锏， 此文当最新PDF版本，可以找40岁老架构师尼恩获取。

当然，上面的面试题以及参考答案，也会收入咱们的 《尼恩Java面试宝典PDF》V171版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

最新《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请关注本公众号【技术自由圈】获取，回复：领电子书

本文作者：

• 第一作者 Moen （负责写初稿 ）

• 第二作者 尼恩 （40岁老架构师， 负责提升此文的 技术高度，让大家有一种 俯视 技术的感觉）

本文目录

- 尼恩说在前面

- 什么是MVCC

- MVCC的根本目标：提升并发能力

- 事务并发处理的四大场景

 - 读-读场景：

 - 写-写场景

 - 读-写、写-读场景

 - 各并发事务场景的解决方案

- 无锁架构：COW思想

 - Java中的CopyOnWriteArrayList

 - MVCC如何使用Copy-On-Write思想呢？借鸡生蛋

 - MVCC与锁的关系

- MySQL事务隔离级别与MVCC

 - 什么是事务

 - 事务的ACID特性

 - 4中事务隔离级别

 - 隔离级别、并发性、数据一致性的三角之间关系

 - 注意：RC/RR 适用MVCC

- MVCC机制的三个核心组件

 - 核心组件1. 隐藏字段

 - 核心组件2. undo log（回滚日志）

 - 核心组件3. read-view

- InnoDB表的四个隐藏字段

 - 隐藏的主键：row_id

 - 隐藏的删除标识：deleted_bit

 - 隐藏的最近更新事务ID：trx_id

 - 隐藏的回滚指针：roll_ptr

- InnoDB引擎的Undo-log日志

- 快照读和当前读

- MVCC核心ReadView

 - 什么是ReadView呢？

 - ReadView的核心属性

 - ReadView的读取规则

 - ReadView的生成规则

- 总结：MVCC实现原理

- 说在最后：有问题找老架构取经

什么是MVCC

在众多的MySQL开源存储引擎中，几乎只有InnoDB实现了MVCC机制，其他的存储引擎如：MyISAM、memory等存储引擎中并未实现MVCC。

1. 版本控制：每当对数据库中的数据行进行更新操作时，不是直接覆盖原始数据，而是创建一个新的数据版本，并将新版本的数据与事务的时间戳相关联。
2. 快照读取：在MVCC中，读取操作不会阻塞写入操作，也不会阻塞其他读取操作。事务可以读取数据库中的数据快照，即某个时间点之前的数据版本，而不会受到其他事务的影响。
3. 可见性判断：在执行读取操作时，事务只能看到在其开始之前已经提交的数据版本，而看不到其他事务正在修改的数据。这样可以避免脏读和不可重复读问题。
4. 回滚操作：当事务回滚时，不会对数据库中的数据进行物理删除或修改，而是标记事务所涉及的数据版本为无效，使得其他事务无法看到该版本。

MVCC的根本目标：提升并发能力

事务并发处理的四大场景

• 读-读、
• 写-写、
• 读-写、
• 写-读，

读-读场景：

写-写场景

读-写、写-读场景

• 读-写是指一个事务先开始读，然后另一个事务则过来执行写操作，
• 写-读则相反，主要是读、写发生的前后顺序的区别。

各并发事务场景的解决方案

无锁架构：COW思想

1. 读取数据：多个线程同时读取共享数据时，它们可以直接访问原始数据，而不需要复制。因为读取操作不会修改数据，所以可以安全地共享原始数据。
2. 写入数据：当某个线程需要修改共享数据时，首先会将原始数据进行复制（即写时复制），然后在副本上进行修改。这样做的好处是，其他线程仍然可以继续读取原始数据，不受写入线程的影响。
3. 更新引用：写入线程完成修改后，会更新共享数据的引用，使得其他线程后续访问时可以获取到最新的数据副本。

• 线程安全：通过复制数据副本并在副本上进行修改，避免了多线程并发修改原始数据时的数据冲突问题，从而提高了线程安全性。
• 减少锁竞争：由于读取操作不需要加锁，所以可以减少锁竞争，提高了并发性能。
• 节省内存：只有在有写入操作时才会进行数据复制，而读取操作可以共享原始数据，因此可以节省内存空间。

Java中的CopyOnWriteArrayList

public boolean add(E e) {
   //加锁，对写操作保证线程安全
   final ReentrantLock lock = this.lock;
   lock.lock();
   try {
       Object[] elements = getArray();
       int len = elements.length;
       //拷贝原容器，长度为原容器+1
       Object[] newElements = Arrays.copyOf(elements, len + 1);
       //在新副本执行添加操作
       newElements[len] = e;
       //底层数组指向新的数组
       setArray(newElements);
       return true;
   } finally {
       lock.unlock();
   }
}

MVCC如何使用Copy-On-Write思想呢？借鸡生蛋

总体来说， MVCC Copy-On-Write思想， 包括三个组成部分：

MVCC与锁的关系

还是一图胜千言，40岁老架构师用一张图，给大家总结一下MVCC和锁如何结合使用，提升事务并行能力的：

1. MVCC：
• MVCC通过维护数据的多个版本来实现并发控制，允许事务并发访问数据库而不会发生阻塞。
• 在MVCC中，读取操作不会阻塞写入操作，也不会阻塞其他读取操作。每个事务可以看到一个一致性的数据快照，而不受其他事务的影响。
• MVCC主要用于读取操作的并发控制，可以有效地避免脏读、不可重复读和幻读等并发问题。
2. 锁：
• 锁是一种悲观并发控制机制，通过在事务访问数据时对数据进行加锁，以防止其他事务对该数据进行修改或读取。
• 在使用锁进行并发控制时，可能会出现阻塞和死锁等问题，特别是在高并发的情况下，锁的粒度过大或者锁的竞争过于激烈时，性能可能会受到影响。

• MVCC是一种 乐观的并发控制机制，通过多副本的版本控制来实现并发访问，而不需要对数据进行加锁。
• 锁是一种  悲观的并发控制机制，通过对数据进行加锁来确保事务的隔离性和一致性。

MySQL事务隔离级别与MVCC

什么是事务

事务的ACID特性

1. 原子性（Atomicity）：事务作为一个整体执行，包含在其中的对数据库的操作要么全部执行，要么全部不执行。
2. 一致性（Consistency）：事务必须使数据库从一个一致性状态变换到另一个一致性状态。也就是说，一个事务的执行不能破坏数据库数据的完整性和一致性。
3. 隔离性（Isolation）：事务的执行不受其他事务的干扰，事务执行的中间结果对其他事务是不可见的。
4. 持久性（Durability）：一旦事务提交，则其结果就是永久性的，即使系统崩溃也不会丢失。
   事务的这些特性确保了即使在高并发的环境中，数据库也能保持数据的完整性和一致性。在数据库系统中，事务是通过一系列的操作来完成的，包括数据的插入、更新、删除等。如果事务中的任何操作失败，或者因为某种原因被中断，那么整个事务都会回滚（Rollback），即撤销所有已经执行的操作，使数据库回到事务开始之前的状态。如果事务中的所有操作都成功完成，那么事务会提交（Commit），所做的更改会永久保存到数据库中。

4中事务隔离级别

• Oracle中默认的事务隔离级别是提交读 （read committed）。
• 对于MySQL的Innodb的默认事务隔离级别是重复读（repeated read）。

1. READ UNCOMMITTED（读取未提交）
• 允许读取尚未提交的数据变更。
• 这是最低的隔离级别，它可能导致脏读、不可重复读和幻读。
• 在这个级别，一个事务可以读取到另一个尚未提交事务的修改，这可能导致数据的不一致性。
2. READ COMMITTED（读取已提交）
• 只允许读取并发事务已经提交的数据。
• 这个级别可以防止脏读，但仍可能导致不可重复读和幻读。
• 在这个级别，每个事务只能看到它开始时的数据状态以及它提交时其他事务所做的提交。
3. REPEATABLE READ（可重复读取）
• 这是MySQL的默认隔离级别。
• 它确保在同一事务中多次读取同一数据时，看到的是相同的数据版本，即使其他事务在此期间修改了这些数据。
• 尽管可以避免脏读和不可重复读，但在这个级别下仍可能出现幻读（即在一个事务中，两次相同的查询可能会返回不同的结果集，因为其他事务在此期间插入了新的记录）。
4. SERIALIZABLE（可串行化）
   选择适当的事务隔离级别需要根据应用的需求和性能考虑进行权衡。在某些情况下，可能需要更高的隔离级别来确保数据的一致性，而在其他情况下，可能需要降低隔离级别以提高性能。同时，也需要注意不同隔离级别可能带来的并发问题，如脏读、不可重复读和幻读等。
• 这是最高的隔离级别。
• 它通过强制事务串行执行来避免脏读、不可重复读和幻读。
• 在这个级别，每个事务在执行时都会完全锁定它所访问的数据，从而确保数据的一致性。但这也可能导致性能下降，因为并发事务必须等待其他事务完成才能执行。

脏读（Dirty Read）：
一个事务读取到另一个尚未提交事务的修改。

不可重复读（Non-repeatable Read）：
在同一个事务内，多次读取同一数据返回的结果有所不同。

幻读（Phantom Read）：
一个事务在执行两次相同的查询时，因为另一个并发事务的插入或删除操作，导致两次查询返回的结果集不同。

隔离级别、并发性、数据一致性的三角之间关系

一图胜千言，40岁老架构师用一张图，给大家总结一下 事务隔离级别、并发性、数据一致性的三角之间关系：

1. 并发性：
• 并发性指的是数据库系统同时处理多个事务的能力。隔离级别越低，允许的并发操作越多，系统的并发性能越高。
• 但是，过高的并发操作可能会导致事务之间的相互干扰，产生一些并发问题，如脏读、不可重复读和幻读。
2. 数据一致性：
• 数据一致性指的是事务执行后，数据库中的数据是否保持一致性。隔离级别越高，数据一致性越好，但对并发操作的限制也越严格。
• 高隔离级别可以防止一些并发问题的产生，如脏读、不可重复读和幻读，但会降低系统的并发性能。

注意：RC/RR 适用MVCC

MVCC机制的三个核心组件

• 隐藏字段
• Undo-log日志
• ReadView。

核心组件1. 隐藏字段

• 在有聚簇索引的情况下每一行记录中都会隐藏3个字段，
• 如果没有聚簇索引的情况下每一行记录中都会隐藏4个字段。

• DB_TRX_ID：记录创建这条数据上次修改它的事务 ID，
• DB_ROLL_PTR：回滚指针，指向这条记录的上一个版本
• deleted_bit字段，即记录被更新或删除，这里的删除并不代表真的删除，而是将这条记录的delete flag改为true

40岁老架构师尼恩提是：隐藏字段的细节，稍后详细介绍。

核心组件2. undo log（回滚日志）

1. 事务的回滚操作：
   当一个事务执行过程中发生错误或者被用户显式回滚时，数据库系统需要能够撤销该事务已经执行的操作，将数据库恢复到事务开始之前的状态。这就是回滚操作。
   undo log记录了事务执行过程中所做的所有修改操作的逆操作，通过undo log可以快速回滚事务所做的修改，从而保证事务的原子性。
2. 恢复和崩溃恢复：
   当数据库系统发生崩溃或者异常关闭时，可能会导致部分事务未提交的修改操作丢失或者部分已提交的修改操作未持久化到磁盘。
   通过undo log，数据库系统可以在恢复过程中, 将未提交的修改操作回滚，并将已提交但未持久化的修改操作重新应用到数据库中，从而保证数据库的一致性和完整性。

核心组件3. read-view

多个事务的 undo-log 日志副本 (数据快照)，组成了一个 副本链，如下图：

1. 已提交数据：事务只能看到已经提交的数据版本。即如果某个数据版本的提交时间早于当前事务的开始时间，则该数据版本对事务是可见的。
2. 未提交数据：事务不应该看到其他事务尚未提交的数据版本。即如果某个数据版本的提交时间晚于事务的开始时间，则该数据版本对事务是不可见的。
3. 事务开始时间：事务开始时间是确定事务 read-view 的关键因素之一。事务只能看到在它开始时间之前已经提交的数据版本。
4. 数据快照：事务读取数据时，read-view 应该是一个一致的数据快照，即事务开始时刻的数据库状态的一个一致性快照。这样可以确保事务读取的数据是在一个一致的时间点获取的。

下面的图中，对于事务4来说，可以看到的数据版本，是事务1的已经提交的数据：

• read view 记录当前活跃事务 id，组成活跃事务id数组 ，这个属性的作用，哪些事务是当前事务，也是不可见的
• read view 记录当前最小活跃事务 id，这个属性的作用，用于判断哪些事务是已经提交了的
• read view 记录当前的下一个事务 id，这个属性的作用，用于判断哪些事务是未来事务，也是不可见的

下面是mysql 的MVCC 的read view 版本对比规则， 确实也是一个非常复杂的对比逻辑， 很多小伙伴傻傻看不懂， 并且背诵了半天还记不住，非常痛苦。

InnoDB表的四个隐藏字段

隐藏的主键：row_id

隐藏的删除标识：deleted_bit

• ①删除表数据时，有可能会破坏索引树原本的结构，导致 叶子节点合并的情况。
• ②事务回滚时，又需重新插入这条数据，再次插入时又会破坏前面的结构，导致 叶子节点分裂 的情况。

• 检查数据库中的数据，识别哪些数据应该被清理。
• 根据一些预定义的规则或条件来决定数据的清理方式，比如按时间戳删除过期数据或者根据某些属性标记数据为无效。
• 执行清理操作，删除或标记需要清理的数据。
• 定期运行，以确保数据库中的数据保持在一个合理的范围内，避免存储空间被不必要的数据占用。

隐藏的最近更新事务ID：trx_id

此时事务T1准备修改表字段的值，MySQL会为其分配一个事务ID=1，当事务T2准备向表中插入一条数据时，又会为这个事务分配一个ID=2......

如果是SELECT语句，则分配的事务ID = 0；

隐藏的回滚指针：roll_ptr

InnoDB引擎的Undo-log日志

1. insert Undo-log : 事务对insert新记录时产生的Undo-log, 只在事务回滚时需要, 并且在事务提交后就可以立即丢弃。
2. update Undo-log : 事务对记录进行delete和update操作时产生的Undo-log，不仅在事务回滚时需要，快照读也需要，只有当数据库所使用的快照中不涉及该日志记录，对应的回滚日志才会被删除。

1.事务回滚时，保证原子性和一致性。 2.如果当前记录行不可见，可以顺着undo log链找到满足其可见性条件的记录行版本(用于MVCC快照读)。

我们来看如下例子，理解一下Undo-log版本链。

如上述这段SQL隶属于trx_id=1的T1事务，其中对同一条数据改动了两次，那Undo-log日志中只会存储两条旧版本的数据，如下图：

细说一下执行上述update语句的详细过程：
1.对ID=1这条要修改的行数据加上排他锁。

2.将原本的旧数据拷贝到Undo-log的rollback Segment区域。

3.对表数据上的记录进行修改，修改完成后将隐藏字段中的trx_id改为当前事务ID。

4.将隐藏字段中的roll_ptr指向Undo-log中对应的旧数据，并在提交事务后释放锁。

1. 一方面可以实现事务点回滚；
2. 另一方面则可以实现MVCC机制。

快照读和当前读

SELECT * FROM USER WHERE ......

SELECT * FROM USER LOCK IN SHARE MODE;

SELECT * FROM USER FOR UPDATE;

INSERT INTO USER VALUES ......

DELETE FROM USER WHERE ......

UPDATE USER SET ......

在RR中，快照会在事务中第一次SELECT语句执行时生成，只有在本事务中对数据进行更改 才会更新快照。

在RC中，每次SELECT都会重新生成一个快照，总是读取最新版本数据。

MVCC核心ReadView

如果T1事务要查询id=1的一条行数据，此时这条行数据正在被T2事务修改，那也就代表着这条数据可能存在多个旧版本数据，T1事务在查询时，应该读这条数据的哪个版本呢？

什么是ReadView呢？

ReadView是事务在进行快照读的时候生成的记录快照, 可以帮助我们解决可见性问题的。

ReadView的核心属性

此时当有一条查询语句执行时，就会利用MVCC机制生成一个ReadView，由于在MySQL中单纯由一条select语句组成的事务并不会分配事务ID，因此默认为0，所以目前这个ReadView的信息如下：

ReadView的读取规则

• 如果被访问版本的 事务ID = creator_trx_id，那么表示当前事务访问的是自己修改过的记录，那么该版本对当前事务可见；
• 如果被访问版本的 事务ID < up_limit_id，那么表示生成该版本的事务在当前事务生成 ReadView 前已经提交，所以该版本可以被当前事务访问。
• 如果被访问版本的 事务ID > low_limit_id 值，那么表示生成该版本的事务在当前事务生成 ReadView 后才开启，所以该版本不可以被当前事务访问。
• 如果被访问版本的 事务ID在 up_limit_id和m_low_limit_id之间，那就需要判断一下版本的事务ID是不是在 trx_ids 列表中，如果在，说明创建 ReadView 时生成该版本的事务还是活跃的，该版本不可以被访问；
• 如果不在，说明创建 ReadView 时生成该版本的事务已经被提交，该版本可以被访问。

具体如下：

• 比如Netty的内存池和对象池（那个超级难，很多人穷其一生都搞不懂），
• 比如DDD的建模和落地，
• 比如Caffeine的底层架构，
• 比如高性能葵花宝典
• 比如 Thread Local 学习圣经
• 等等等等。

ReadView的生成规则

在RR中，ReadView会在事务中第一次SELECT语句执行时生成，只有在本事务中对数据进行更改才会更新快照。

在RC中，每次SELECT都会重新生成一个ReadView，总是读取最新版本数据。

读已提交和可重复读唯一的区别在于：

1.在RC隔离级别下，是每个select都会创建最新的ReadView；

2.而在RR隔离级别下，则是当事务中的第一个select请求才创建ReadView。

总结：MVCC实现原理

• 当一个事务尝试改动某条数据时，会将原本表中的旧数据放入Undo-log日志中。
• 当一个事务尝试查询某条数据时，MVCC会生成一个ReadView快照。
  其中Undo-log主要实现数据的多版本，ReadView则主要实现多版本的并发控制。
  结合如下例子说明：

-- 事务T1：trx_id=1

UPDATE user_info  SET name = "小夏" WHERE id = 1;
UPDATE user_info  SET sex = "女" WHERE id = 1;

-- 事务T2：trx_id=2

SELECT * FROM  user_info  WHERE id = 1;

• 1.当事务中出现select语句时，会先根据MySQL的当前情况生成一个ReadView。
• 2.判断行数据中的隐藏列trx_id与ReadView.creator_trx_id是否相同：
• 相同：代表创建ReadView和修改行数据的事务是同一个，自然可以读取最新版数据。
• 不相同：代表目前要查询的数据，是被其他事务修改过的，继续往下执行。
• 3.判断隐藏列trx_id是否小于ReadView.up_limit_id最小活跃事务ID：
• 小于：代表改动行数据的事务在创建快照前就已结束，可以读取最新版本的数据。
• 不小于：则代表改动行数据的事务还在执行，因此需要继续往下判断。
• 4.判断隐藏列trx_id是否小于ReadView.low_limit_id这个值：
• 大于或等于：代表改动行数据的事务是生成快照后才开启的，因此不能访问最新版数据。
• 小于：表示改动行数据的事务ID在up_limit_id、low_limit_id之间，需要进一步判断。
• 5.如果隐藏列trx_id小于low_limit_id，继续判断trx_id是否在trx_ids中：
• 在：表示改动行数据的事务目前依旧在执行，不能访问最新版数据。
• 不在：表示改动行数据的事务已经结束，可以访问最新版的数据。
  然后经过上述一系列判断后，可以得知：目前查询数据的事务到底能不能访问最新版的数据。
  如果能，就直接拿到表中的数据并返回，反之，不能则去Undo-log日志中获取旧版本的数据返回。

总结

说在最后：有问题找老架构取经

部分历史案例

• 绝地逢生：9年经验自考小伙伴，跟着尼恩狠卷3月硬核技术，面试机会爆表，2周后收3个offer ，满血复活

• 硬转架构：35岁被裁6个月 职业绝望，转架构急救上岸，DDD和3高项目太重要了
  

• 逆天改命：3年经验2本，卷3个月涨薪60%，进准大厂(得物、乐信、58集团等)，年薪36W

• 女35岁CRUD程序媛，12月被裁后，拿30个机会2个offer上岸，年底大裁员太不容易了

• 38还有救吗？有。42岁被裁2年天快塌了，急救1个月上岸，成开发经理offer，起死回生

• 被裁不慌，9年小伙1个月喜提年薪60W offer，做中间件架构，爽歪了

• 12年小伙转架构，1小时蜕变收年薪55万offer，秘诀：GO+Java双栖架构

• 年薪百万：40岁小伙被裁6个月，跟着尼恩猛卷3月硬核技术，100W年薪逆袭 ，上岸秘诀：首席架构/总架构

• 不怕裁员，8年小伙去中年危机，秘诀：换架构师赛道，上得厅堂，下得厨房，越早越好

• 被裁员后因祸得福，拿N+1后，逆涨30%，如何实现？

• 逆天啦：4年crud小伙收shein+银行两优质offer，狠卷1月收年薪43万大涨30%

• 原来，拿大厂offer 有捷径......

• 太劲爆.... 被裁4个月，38岁Android转Java，2个月提架构offer

• 起死回生：8年小伙高中毕业+频繁跳槽，狠卷2月，提Java高级offer

• 爽翻了：指导3轮，5年小伙收5大offer，涨50%，领路模式太牛

• 降维攻击，37年大龄老伙喜提60W年薪offer，1个月顺利上岸

• 架构速成：从一面杀到一次过，记7年女架构的速成经历

• 极速拿offer：阿里P6被裁后极速上岸，1个月内喜提2优质offer(含滴滴)

• 大逆袭：做化工12年，35岁转Java，被裁4个月后，1个月收架构Offer，大龄跨行，超级牛

• 被裁后炸爽：10年小伙12天火速上岸，反涨20%，爽暴了

• 裁就裁，6年小伙60W极速上岸，白拿20W还游一圈拉萨，真香

• 极速拿offer：被毕业3个月，11年经验小伙0.5个月极速拿offer，领路模式的巨大威力

• 惊天大逆袭：8年小伙20天时间提75W年薪offer，逆涨50%，秘诀在这