MySQL是如何实现事务隔离？

前言

　　众所周知，MySQL的在RR隔离级别下查询数据，是能够保证数据不受其它事物影响，而在RC隔离级别下只要其它事物commit后，数据都会读到commit以后的数据，那么事物隔离的原理是什么？是经过什么实现的呢？那确定是经过MVCC机制（Multi-Version Concurrency Control，即多版本并发控制），这是不少人知道的，可是我以前没有好好分析过其实现原理，因此写下此篇博文记录下!

　　注：MySQL的InnoDB引擎之因此可以支持高性能的并发性能，就是因为MySQL的MVCC机制（归功于undo log、Read-View、），可是本篇不对MVCC过多的介绍。

　　参考资料：《MySQL实战45讲》系列，虽然讲解的比较清晰，可是仍然须要理解，好比关于视图数组部分我认为是相比较而言没有解释清楚，因此结合资料与本身看法加以记录！

 

---

 

1、RC与RR隔离级别

咱们分别开启RC与RR隔离级别实验说明，首先假设有account帐户表，在事务ABC开启前，帐户中的余额balance为1，即

select balance from account =1; # 结果为1

1.RR事务隔离级别下查询结果

当在RR事务隔离级别分别开启三个事务，在不一样时间段内作以下操做

• 事务A（显式开启事务，手动commit提交）：查询余额
• 事务B（显式开启事务，手动commit提交）：对id=1的余额加1
• 事务C（不显式开启事务，自动提交）：对id=1的余额加1

 咱们从时间逻辑上分为三个阶段，分析结果

• 第一阶段：事务A立马开始事务，随后事务B也紧跟着立马开始事务，而后事务C首先更新balance为2成功，当前balance=2；
• 第二阶段：事务B更新balance的值，此时先读到当前balance最新值为2，随后set balance=balance+1成功，当前balance=3；
• 第三阶段：事务A查询balance的值，此时的值为1（这里为何等于1呢，是怎么实现的呢？不该该是当前最新值3吗？这就是本篇博文讨论的重点），最后commit结束事务，紧接着事务B也commit结束事务

 最后事务A读取balance的结果是1，理所固然，RR即为可重复读，即一个事务在执行过程当中看到的数据，老是跟这个事务启动时看到的数据是一致的，当前事务无论有没有提交，都不会影响数据，我只须要读取基于快照的数据便可，这就是快照读。可是咱们要讨论的是如何在MVCC机制下实现？

注：begin/start transaction 命令并非一个事务的起点，在执行到它们以后的第一个操做InnoDB表的语句，事务才真正启动。若是你想要立刻启动一个事务，可使用start transaction with consistent snapshot 这个命令。

1.RC事务隔离级别下查询结果

一样地，咱们在RC隔离下，开启事务ABC，观察事务A最后的balance结果。

 最后事务A读取balance的结果是2，理所固然，RC即为读可提交，字面意思就是其余事务只要提交后，当前事务我就能立马读取到最新当前值，这就是当前读。可是咱们要讨论的是如何在MVCC机制下实现？

　实际上这是由于实现MVCC时用到的一致性读视图，即consistent read view，用于支持RC（Read Committed，读提交）和RR（Repeatable Read，可重复读）隔离级别的实现。

3、事务隔离在MVCC的实现

在探讨MVCC如何实现事务隔离前，咱们须要知道是视图数组、一致性视图等概念，才能帮助更好理解MVCC帮助事务实现了隔离。

1.数据行ROW的多版本

　　InnoDB里面每一个事务有一个惟一的事务ID，叫做transaction id。它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的。

　　而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，而且把transaction id赋值给这个数据版本的事务ID，记为row trx_id。同时，旧的数据版本要保留，而且在新的数据版本中，可以有信息能够直接拿到它（经过undo_log文件找到）。

　　也就是说，数据表中的一行记录，其实可能有多个版本(row)，每一个版本有本身的row trx_id。

　　对某一个数据行ROW某个时刻通过三次更新事务的多版本控制流程，画以下图加深理解。

从图咱们能够获得：

• ROW有四个版本V1-V4，即通过三次更新balance后，当前最新版本为V4，当前balance已经更新为4，是最新值
• InnoDB每次更新事务产生的transaction id都会赋值给row trx_id；
• 经过undo_log能够从V4撤回到V1,找到V1版本的balance=1，即undo_log回滚版本。

明白了数据行的ROW的多版本原理与实现后，能够帮助咱们理解InnoDB是怎么定义并建立快照的！

2.视图数组

　　下述部分出自资料中的原句，特别是红色加深部分可能会比较难以理解，因此须要结合本身理解并画图

InnoDB是这么在事务开启的时候定义快照的，哪些事务的操做我能够忽视，哪么我必需要保存在快照里。能够理解为：一个事务只须要在启动的时候声明说，“以我启动的时刻为准，若是一个数据版本是在我启动以前生成的，就认；若是是我启动之后才生成的，我就不认，我必需要找到它的上一个版本”。

　　在实现上， InnoDB为每一个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”的全部事务ID。“活跃”指的就是，启动了但还没提交。数组里面事务ID的最小值记为低水位，当前系统里面已经建立过的事务ID的最大值加1记为高水位。这个视图数组和高水位，就组成了当前事务的一致性视图（read-view）。

我对低水位与高水位的理解：

低水位=当前全部启动了但未提交事务集合的ID最小值=当前事务的上一个启动但未提交的事务ID最小值（全部活跃事务ID最小值）

高水位=当前事务的ID（当前ROW版本号/row trx_id）=已经建立过事务ID的最大值+1

举例说明：仍然以上述RR隔离级别下三个ABC事务为例

• 事务A开始前，系统里面只有一个活跃事务ID是99；
• 事务A、B、C的版本号分别是100、10一、102，且当前系统里只有这四个事务；
• 三个事务开始前，(id,balance)=(1,1）这一行数据的row trx_id是90。

这样，事务A的视图数组就是[99], 事务B的视图数组是[99,100], 事务C的视图数组是[99,100,101]。即视图数组通用公式为：[{当前事务开启瞬间活跃事务ID集合}]。

 而数据版本的可见性规则，就是基于row trx_id和一致性视图对比结果获得的，因此咱们还必须再了解下一致性视图

3.一致性视图

经过对视图数组的理解，一致性视图就更加容易了，即：这个视图数组和高水位，就组成了当前事务的一致性视图（read-view）。

仍然以上述RR隔离级别下三个ABC事务为例

• 事务A开始前，系统里面只有一个活跃事务ID是99, 因此事物A开启瞬间活跃事物集合为[99]；
• 事务A、B、C的版本号分别是100、10一、102，且当前系统里只有这四个事务，因此事物A、B、C高水位分别为100、10一、102；
• 三个事务开始前，(id,balance)=(1,1）这一行数据的row trx_id是90。

 这样，事务A的一致性视图就是[99,100], 事务B的一致性视图是[99,100,101], 事务C的一致性视图是[99,100,101,102]。即一致性视图通用公式为：[{当前事务开启瞬间活跃事务ID集合}，当前row trx_id]。

分析上述流程图结果：

第一个有效更新版本是事物C，更新balance=2，这个时候的最新版本row trx_id=102，而以前的在事物ABC以前的活跃事物最新版本row trx_id为99，因此此时99已经成为历史版本1；

第二个有效更新版本是事物B，更新balance=3，这个时候最新版本row trx_id=101，而此时row trx_id=102成为历史版本1，而row trx_id=99成为历史版本2；

事物A查询的时候，事物B是没有提交，但生成的(id, balance)=(1, 3)已经成为当前最新版本，事物A读取数据时，一致性视图为[99, 100]，而读数据都是从当前版本切的而后对比row trx_id，因此会有如下流程：

• 找到(1,3)的时候，判断出row trx_id=101，比高水位大，处于红色区域，不可见；
• 接着，找到上一个历史版本，一看row trx_id=102，比高水位大，处于红色区域，不可见；
• 再往前找，终于找到了（1,1)，它的row trx_id=90，比低水位小，处于绿色区域，可见。

最后事物A不管在何时查询，看到的数据都是一致性视图[99, 100]生成的快照数据(1, 1)，即row trx_id=90时的数据。这就称之为一致性读。

总结：

对于一个事务视图来讲，除了本身的更新老是可见之外，有三种状况：

• 版本未提交，不可见；
• 版本已提交，可是是在视图建立后提交的，不可见；
• 版本已提交，并且是在视图建立前提交的，可见。

如今，咱们用这个规则来判断图中的查询结果，事务A的查询语句的视图数组是在事务A启动的

时候生成的，这时候：

• (1,3)还没提交，属于状况1，不可见；
• (1,2)虽然提交了，可是是在视图数组建立以后提交的，属于状况2，不可见；
• (1,1)是在视图数组建立以前提交的，可见。

4.当前读与快照读

（1）当前读与快照读规则

　　固然按照这个一致性读的逻辑，事物B在事物C有效更新balance=2以后，可是事物B的视图数组是在事物C生成的，因此理论上来讲不该该是事物B看到的是(id, balance)=(1, 1)这个数据（快照/历史版本）吗？而看不到当前版本(1, 2)数据。为何事物B在更新balance以后直接数据就成为(1, 3)了呢？

　　若是事物B在update以前select一次数据，看到的值确实是balance=1，可是update是不能在历史版本上操做的，不然事物C的更新就会丢失，因此update操做都是在先读取当前版本，而后再更新。

　　也就说有这么一条规则：更新数据都是先读后更新，而这个读是读当前最新值，称之为“当前读（current read），而只查询不读的话就会读取当前快照，称之为“快照读”。因此在事物B更新balance以前，先查询到最新的版本(1, 2)而后再更新为(1, 3)。而事物A查询的快照数据为(1, 1)，而不是最新版本(1, 3)。

（2）当前读与快照读解释

　　当前读：像select lock in share mode(共享锁), select for update ; update, insert ,delete(排他锁)这些操做都是一种当前读。就是它读取的是记录的最新版本，读取时还要保证其余并发事务不能修改当前记录，会对读取的记录进行加锁。

　　快照读：像不加锁的select操做就是快照读，即不加锁的非阻塞读；快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读。是基于多版本控制的，那么快照读可能读到的并不必定是数据的最新版本，而有多是以前的历史版本（快照数据）。

（3）RC读可提交下的视图规则

读提交的逻辑和可重复读的逻辑相似，它们最主要的区别是：

• 在可重复读隔离级别下，只须要在事务开始的时候建立一致性视图，以后事务里的其余查询，都共用这个一致性视图；
• 在读提交隔离级别下，每个语句执行前都会从新算出一个新的视图，此时start transaction with consistent snapshot就等同于普通的start transaction/begin

因此在RC隔离级别下，事物A与事物B查询到的数据分别以下：

• 事物C立马更新balance=2，而后自动提交，生成最新版本(1, 2)，此时从新计算出视图数据(1, 2);
• 事物B查到此时的最新版本为(1, 2)，以后再更新为版本(1, 3)为当前最新版本，查询此时的事物B select到的balance=3（事物B更新balance=3以后立马算出一个新的视图，select就是根据此视图获得的数据），而不是1。
• 而此时事物B还未提交，对于事物A来讲是看不见的，因此事物A此时读取到的事物C提交的最新版本(1, 2)。