--- theme: smartblue highlight: tomorrow-night-blue --- # 详解MySQL的事务和MVCC原理

1. 什么是事务？事务带来什么问题？如何解决？

2. MVCC是什么？它的原理是什么？用它解决了什么问题？

## 事务是什么？ > **事务**是我们学习MySQL时，永远绕不开的话题。我们知道，当一个系统**多线程运行**时，**并发**带来的问题永远是最主要考虑解决的。因此，而MySQL用来**解决并发问题的关键词即为事务**。 **事务**主要将围绕以下几个维度展开，如图：

### 什么是事务？ > 事务的**基本概念**要先了解，我个人的理解是：**要么有始有终，要么其实都没有** 有一场景，**用户A需要向用户B转账1000块钱**，我们将步骤细分为**四步**，如下： - 从数据库读取用户A的余额 - 用户A的余额**扣1000元**（如果余额>1000），将**扣完的余额**更新到数据库 - 从数据库读取用户B的余额 - 将用户B的余额**加1000元**，将**增加后的余额**更新到数据库

试想？如果在**第二步，用户A的余额扣完后，服务器断电了**，这1000元不是直接**不翼而飞**了？这换做谁都无法接受吧！ **因此，便有了事务这一概念**。MySQL通过**事务**来解决这一问题。在**原先转账操作的基础**上，在**转账前后分别开启事务和提交事务**。如果开启事务后，中途发生意外（报错了，或是服务器断电），直接将 **“这件事” 退回**到事务**开启前**的状态。如果顺利执行完，就将事务提交，完毕！总结来说，就是**在一开始做事的时候，有个标记在初始位置，如果发现情况不对，赶紧跑回去。** 如果一切顺利，就不用管了。 ### 事务四大特性总结 > 事务肯定是有特点的嘛，分别是**原子性，持久性，隔离性，一致性**。下面我们分别展开说说！ #### 原子性如何理解原子性？我个人的理解是：**原子是世界上最小的单位**，肯定是无法再做**切割**的。整个**事务可以看成是一个原子**，无法将事务**再拆分开**。因此**一次事务内的所有操作**，肯定是要么**全部成功**，要么直接**挫骨扬灰**（全部失败）。事务的原子性由 **undo log回滚日志**来保证（后续会展开说） #### 持久性如何理解持久性？上文提到的转账操作，如果**事务提交了，还可以修改，或者是回滚**，那问题可就麻烦了。那需要事务来做什么？因此，事务的持久性代表了：提交的事务是**不可被修改的状态**，已经**彻底保存了下来**。事务的持久性由 **redo log回滚日志**来保证（后续会展开说） #### 隔离性如何理解隔离性？如果**同时有多个事务在运行**，事务之间可以**互相看到对方的事务**，并**修改对方事务内的信息**，那事务就会彻底乱套啦。因此事务的隔离性代表：**未提交的**事务之间**相互不可见**，**不可修改对方事务内的信息**，保证**数据一致性**。事务的持久性由 **MVCC机制和上锁**来保证（**持久性是锁篇的重点**） #### 一致性如何理解一致性？事务的一致性表示，事务的操作前后的数据需要保持**完整性约束**。（例如，上述例子提到的**1000块转账钱**，**只是从A账户跑到了B账户**，并没有凭空消失，这就是**数据的完整性**）由**原子性+持久性+一致性**共同守护。 ### 事务的并发问题 > 如果整个世界只允许单线程的细胞生物存在就好了，哈哈哈！上到各门编程语言，下到操作系统，并发的问题总是会被提到，**MySQL的事务也不例外**。肯定是允许多事务并发的，也会带来一些并发问题，**总结**如下： #### 脏读如何理解脏读？假设有两个正在运行的事务，**事务A能读取到事务B的未提交的数据**，表明**发生了脏读**。这个问题就很严重啦！我画了个图举例，如下：

如果**发生了脏读**，那就表明**在t5时刻查到的余额V1为2000**，如果这时候是有两个人在做交易： - B在**t5时刻给A看完余额记录** - 随后**在t6时刻**，再把**事务不是提交，而是直接回滚** - **在t7时刻**，查询到的**余额V2为1000**。这样就涉及到诈骗了！脏读是**绝对不允许**发生的！ #### 不可重复读如何理解不可重复读？不可重复读是在**解决了脏读的基础上**，存在的其它问题。具体为：**一个正在活跃的事务，在不同时刻查询到的数据不一致。**，还是同样的图：

如果**发生了不可重复读**，即： - 在t4时刻，事务B将余额修改为2000，**没有提交** - 在t5时刻，事务A查到的余额V1为1000，**没有出现脏读现象** - 在t6时刻，事务B把事务提交了 - 在t7时刻，事务A再次查询余额，此时**读到其他提交的事务的值**，查到的余额**V2为2000**，出现了**不可重复读问题** #### 幻读如何理解幻读？在**处理了脏读和不可重复读**后，幻读的具体为：**一个正在活跃的事务，在不同时刻查询到的数据的数量不一致**。幻读更多关注的是**数量**，多次查询某个条件的数量，出现数量不一致的情况，如图：

如果**发生了幻读**，即： - 在t2时刻，查询到符合条件的**用户数量为5** - 在t4时刻，新启动的事务B将**插入一条新用户**，并随后提交 - 在t6时刻，事务A再次执行相同的sql，此时**查询到符合条件的用户数量为6**，和一开始的数量对不上，出现了**幻读问题** **总结下事务的并发问题:** 1. 从**严重性**考虑，脏读＞不可重复读＞幻读 2. 从性质分类，脏读：读到其他事务**未提交**的数据；不可重复读：前后读取的**数据**不一致；幻读：前后读取的数据**数量**不一致 ### 事务的隔离级别 > 既然让事务并发操作，会带来这么多问题，那MySQL就**不可能不处理**这些问题，让这些问题**破坏我们的数据**。针对这不同的问题，MySQL同样有多种隔离级别来应对。分别是：**读未提交，读提交，重复读，串行化** #### 从安全性考虑

#### 从会产生的问题考虑

1. **读未提交 = 安全裸奔**，什么安全性都不顾，只要速度！ 2. **读提交**，可以**解决脏读问题**，但仍然存在不可重复读和幻读。是Oracle的默认隔离级别 3. **重复读**，可以**解决脏读，不可重复读，绝大多数幻读（个例除外）**，是MySQL的默认隔离级别 4. **串行化**，不会存在并发问题，直接让**事务变成读写互斥操作**，一劳永逸，但性能最低 #### 不同隔离级别下读到的数据

1. 如果隔离级别为**读未提交**，**事务可以读到未提交的事务的数据**，因此**V1为2000，V2为2000**。 2. 如果隔离级别为**读提交**，可解决脏读，但会出现不可重复读问题，**因此V1为1000，V2为2000**。 3. 如果隔离级别为**读提交**，可解决绝大多数并发问题，**因此V1为1000，V2也为1000**。 4. 如果隔离级别为**串行化**，在**事务A执行读操作后，没提交事务；事务B执行写操作时，会发生阻塞，直到提交**。 #### 隔离级别的原理我们在写sql时，**执行单条insert, update, delete语句**时，MySQL会**默认开启事务**（在sql的前后默认加上begin（开启事务）, commmit（提交事务））。而执行关键的**查询select sql**时，有两种写法： - 普通的select ... 语句（**快照读**），会通过**MVCC**的方式来解决事务的并发问题 - select ... for update（**当前读**），会通过直接**给数据加锁**的方式来解决事务的并发问题而根据**不同的隔离级别，MVCC和上锁的粒度也有所不同**，我会在后续展开详细介绍 --- ## MVCC是如何解决事务并发问题的？ > 在上章节我们提到，**普通的select**语句是通过**MVCC**的方式来解决事务的并发问题，**MVCC（多版本并发控制）** 是我们这次介绍的重点，具体从**以下三部分**展开：

### 什么是MVCC？在介绍MVCC之前，我们需要了解几个基础的概念。一. 普通的MySQL记录，还有几个我们看不到的**隐藏字段**： - trx_id: **最近的操作这条数据的事务ID**；（对一条记录**做增删改**时，会在这条记录上**留下“我是谁”的印记**，即**事务ID**） - roll_pointer: **回滚指针，指向该条记录的上一个版本**：（一条数据**修改后**，**旧记录并不是被直接抹去**，而是有**新纪录的指针**会指向它） - row_id: 虚拟字段，**若表中没有主键，起到代替主键的作用** 举个例子，数据的变更图如下。在t1时刻，由**id为50的事务创建了id = 1的记录**，此刻他的**trx_id为50**，由于是**新记录**，**roll_pointer为NULL。** 在t2时刻，由**id为51的事务修改了id = 1的记录**，将age从20改成18。等于**这条记录的版本被更新了**。当前最新版本记录的**trx_id为51**，而**roll_pointer则会指向当前记录的上一个版本。**

二. **Read View**（视图），MVCCd的**重要组成**，可以理解为**数据的快照**，**相机的快门**，**每生成一个Read View时（按一下相机快门），总会有一些记录（图片）被保存下来**。以下是Read View的关键内容： - create_trx_id：**创建这个read view的事务ID** - m_ids: 创建这个read view时，**当前还活跃的事务ID集合**（事务是允许并发的嘛!） - min_trx_id: 当前还**活跃的事务最小ID**，即m_ids集合中的**最小值** - max_trx_id: 下一个**即将创建的事务的ID**。相当于是一种**预分配**，提前告诉这个read view会有哪个事务会来，**但是现在还没来！**

通过上述的基本概念，我们就可以系统性的学习MVCC是如何工作的，**read view, rtx_id, roll_pointer**... ### 如何用MVCC来判定当前的数据是否可见（MVCC工作原理）？ > 如何理解**数据是否可见这句话？** 其实就是**在查询数据时**，**查到了本不应该让他看到的数据**，才导致的并发问题。比如说：**脏读：查到了其他事务还没提交的数据**；**不可重复读和幻读：自己的数据还没提交，查到了其他事务提交的数据** MVCC是如何利用Read View来判断数据是否可见的？当前我开启了一个事务，其中有查询语句，并且手里有一个read view，判别步骤如下： 1. 获取查询到的**符合筛选条件的行数据**，将当前行数据的最新版本的**trx_id**取出来 2. 如果**trx_id == create_trx_id**, trx_id和read view中的create_trx_id相同，表明**这条记录的当前版本**是**我这个事务创建的**。**可见**，直接返回当前的记录 3. 如果**trx_id < min_trx_id**，trx_id小于当前活跃事务的最小id，表明这条记录的当前版本已经被提交了（**事务的id是持续递增的**），**可见**，直接返回当前的记录 4. 如果**trx_id ∈ m_ids**, trx_id包含在read view中的m_ids中，表明这条记录的当前版本还是**活跃**的，如果可见，那就直接发生脏读了，**肯定不可见**。**因此MVCC天生就会避免脏读**，继续判断 5. 如果**trx_id >= max_trx_id**，trx_id大于等于read view中的max_trx_id，表明这条记录的当前版本对于这个read view来说，**还未创建**！肯定**不可见**，继续判断 6. 如果没有找到可见记录，则通过**隐藏列中的回滚指针**，找到**这条记录的上一个版本**，**重复步骤2-5**，直到找到为止。 **判别流程图**可以总结为如下：

可以看下**伪代码**： ``` row_data = select ...; while (row_data != null){ if (row_data.trx_id == read_view.create_trx_id) { break; } if (row_data.trx_id < read_view.min_trx_id) { break; } if (read_view.m_ids contains row_data.trx_id) { row_data = row_data.poll_pointer; continue; } if (row_data.trx_id >= read_view.max_trx_id) { row_data = row_data.poll_pointer; continue; } } return row_data; ``` ### 不同隔离级别下的MVCC是如何工作的？ > **读未提交**不谈（这玩意没有任何防御措施），重点是**读提交和重复读两种隔离机制**，MVCC**开启Read View的时机**不同，因此安全性也不同对于重复读隔离级别，整个事务的运行阶段，**只会创建一个Read View**，事务内执行的select语句**共用**一个read view。（**从一而终**）对于读提交隔离级别，整个事务的运行阶段，只要**执行一次select语句**，就会**马上创建一个Read View**，然后用这个新的Read View做可见性判断。（**始乱终弃**）那在重复读的隔离级别下，**创建唯一的Read View的时机**？ 1. 如果是通过**begin**开启的事务，只有在第一次执行select语句的时候才会创建Read View（类似**懒加载**的机制） 2. 如果是通过**start transiction with consistent snapshot**开启的事务，在创建的时候马上就会创建Read View（类似**饿汉式加载**机制） #### 读提交下的MVCC 举个例子，下面是**两个事务在不同时刻对某条相同记录执行的CRUD操作**，

一. 在T5时刻，事务B对余额要做一次查询操作，此时会创建一个Read View，如下：

根据判断规则，余额的**最新记录为2000**，这是由**id为50**的记录创建的，该read_view的**最小活跃事务ID为51**，小于min_trx_id。因此，该版本记录对于这个read_view是可见的，**余额V2=2000**。一个事务内前后时刻读取的数据不一致，**出现了不可重复读的并发问题**。 #### 重复读下的MVCC 还是相同的例子，隔离级别升级为重复读

一. 在T5时刻，事务B对余额要做一次查询操作，此时会创建一个Read View，如下：

根据判断规则，余额的**最新记录为2000**，这是由**id为50**的记录创建的，该read_view的**活跃事务id集合为[50, 51]**，**50的事务对于当前的read_view是不可见**的。因此，通过**回滚指针**找到**上一条版本记录**，即**余额为1000**，而余额为1000的记录则是由**id < 50的事务创建**的，小于min_trx_id。因此，该版本记录对于这个read_view是可见的，**余额V1=1000**。二. 在T7时刻，事务B**再次**对余额做一次查询操作，由于是重复读隔离级别，因此**不会创建新的Read View**，**复用**T5时刻创建的Read View。因此，时刻T7的判断和T5相同，**余额V2仍然为1000**。**不可重复读**的问题解决。从理论上来说，一个事务内，对**任何查询都沿用同一个read_view**，在这个期间**无法看到其他事务插入的数据**，也能**避免幻读问题**（除个例）。 ### MVCC真能完全解决幻读嘛？毫无疑问，在重复读隔离级别下，对于**普通的幻读**，**MVCC是可以避开的**，如下图：

在**t3时刻**再次执行**t2时刻**的select语句，由于**t3时刻使用的read view的和t1时刻的一样**。因此，在t2时刻，**执行的insert语句对于该read_view是不可见的**，因此**select语句的结果仍然可以和t1时刻的保持一致**。 > 但如果是**本事务**去**对其他事务insert的数据**做**修改**呢？在讲解之前，需要科普一下**快照读和当前读的概念** - 快照读：**读的是数据的版本**，（读取到的不一定是最新的版本，因为有可能不可见）。**普通的select ...** 用的就是快照读 - 当前读：**读的是一定是数据的最新版本**。执行**insert, update, delete**用的都是当前读（需要知道操作数据的最新值，才能操作）; 还有特殊的 **select ... for update**语句。 #### 特例一：两次select间穿插update **存在一张user表，该表里面没有数据**，存在字段id, age, mal5。

一. 在T1时刻，A开启事务，执行select语句，由于**表没有数据**，因此**查询结果为NULL** 二. 在T2时刻，B事务**插入了一条id=10的数据**，并马上提交事务三. 在T3时刻，事务A执行一条**update**语句，需要对**id = 10的数据做更新**，此时采用的是**当前读**，由于数据库有**一条已经提交了的id = 10的数据**，因此能读到，并修改。**此时，id=10这条记录的最新版本的trx_id为事务A** 四.在T4时刻，事务A执行同样的select语句，此时对于id=10这条记录来说，**最新版本的记录的trx_id为事务A**，正好满足条件：**read_view.create_trx_id == trx_id**。结果为**可见**，尴尬的幻读问题出现了。 #### 特例二：两次select; 一次select, 一次select...for update **还是同样的表**，执行顺序变为如下：

一. 在T1时刻，A开启事务，执行select语句，由于**表没有数据**，因此**查询结果为NULL** 二. 在T2时刻，B事务**插入了一条id=10的数据**，并马上提交事务三. 在T3时刻，事务A执行的是**select ... for update**，不同于普通的select，为**当前读**，一定会读取**数据最新的版本**，事务B提交的记录对其是**可见**的，尴尬的**幻读**问题又出现了！ ### 思考题，为何我的数据修改了不生效呢？ > 看下图，开启事务后，执行第一次select语句的时候，我们可以看到表里的数据，**所有的id值均等于age值**，随后**执行了一条update语句**，再次执行**同样的**select语句，为什么**数据没有改变？** 什么样的场景能复现该操作？

其实问题的关键在于：执行了update语句，**受到影响的行数居然为0**。**数据必然是提前被其他事务修改了**。答案如下：

一. 在T1时刻，A开启事务，执行select语句，正常返回数据，可以看到**所有的id均等于age** 二. 在T2时刻，B事务**将表里的age全部+1**，并马上提交事务三. 在T3时刻，事务A执行的是**update语句**，将**id == age**的数据中的age都**修改为0**。此刻会进行**当前读**，读取最新数据。由于**最新数据的age全被+1**，已经**不满足id == age**这个条件，因此**受影响的行数为0**。四. 在T4时刻，事务A再次执行的是**普通的select语句**，为**快照读**。这时候会从数据的最新版本开始查找，事务A此时用的read_view是在T1时刻创建的，（此时**事务B操作的sql均不可见，trx_id >= read_view.max_trx_id**，对于**当时的事务A**来说，**事务B还没创建**，所以肯定是读不到的）。因此会通过**行的roll_pointer查找到上个版本的数据**，因此查找的数据仍和T1时刻**相同**！！ --- **总结下MVCC的工作原理** 对于事务产生的**脏读，不可重复读，幻读问题**。对于MVCC来说，活跃的事务数据均是不可见的，因此脏读问题自然解决。 MVCC的**读提交隔离级别**，生成的是**语句级别**的快照Read View（每次select都会创建），不可重复读，幻读问题仍然存在。 MVCC的**重复读隔离级别**，生成的是**事务级别**的快照Read View（一个事务只会有一个），从**开始到结束都会保持一致**。即使有别的事务插入和修改数据，**对于普通的快照读都是不可见的**，因此可解决不可重复读和幻读问题 > 未完待续...........还会讲MySQL的锁，上锁规则，死锁分析...重量级的还没来