MySQL深入06-事务隔离再探
# 事务隔离再探
如果是可重复读隔离级别，事务T启动的时候就会创建一个视图，之后在该事务执行的过程中，即使其他事务修改了数据，事务T看到的数据仍然和启动时看到的一样。
而在行锁中，一个事务要更新一行，如果刚好另一个事务拥有这一行的行锁，那么这个事务就会被锁住，需要等待。那么等到这个事务自己获取到行锁要更新数据的时候，它读到的值又是什么呢?
在MySQL里，有两个“视图”的概念：
- 一个是view，是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是 create view … ，而它的查询方法与表一样。
- 另一个是 InnoDB 在实现 MVCC 时用到的一致性读视图，即 consistent read view，用于支持 RC（Read Committed，读提交）和 RR（Repeatable Read，可重复读）隔离级别的实现。
consistent read view是没有物理结构的，作用是事务执行期间用来定义"能看到什么数据"。
# 快照在MVCC的工作原理
在可重复读隔离级别下，事务在启动的时候就对整个库拍了个照片。
但是这个照片并非我们所理解的拷贝整个库。
InnoDB 里面每个事务有一个唯一的事务 ID，叫作 transaction id。它是在事务开始的时候向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。
而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把 transaction id 赋值给这个数据版本的事务 ID，记为 row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。
相当于一行数据，在不同事务下有对应的版本，每个版本有自己的row_trx_id。
目前k=22，它是被transaction id为25的事务由11改变成22，因此它的row_trx_id为25。
其实这个就是我们的undo log，而 V1、V2、V3 并不是物理上真实存在的，而是每次需要的时候根据当前版本和 undo log 计算出来的。如果我们要得到V2，就是通过 V4 依次执行 U3、U2 算出来。
那么再回到我们刚才的拍照的问题：
按照可重复读的定义，一个事务启动的时候，能够看到所有已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可见。
因此在启动的那一刻，事务只认在启动时刻之前的数据版本，对于超出启动时刻的数据版本，就需要通过undo log找到所认可的上一个版本。
当然，如果“上一个版本”也不可见，那就得继续往前找。还有，如果是这个事务自己更新的数据，它自己还是要认的。
在实现上， InnoDB 为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务 ID。“活跃”指的就是，启动了但还没提交。
数组里面事务 ID 的最小值记为低水位，当前系统里面已经创建过的事务 ID 的最大值加 1 记为高水位。
这个视图数组和高水位，就组成了当前事务的一致性视图（read-view）。
这样，对于当前事务的启动瞬间来说，一个数据版本的 row trx_id，有以下几种可能：
如果落在红色区域，表示这个版本是将来事务创建的，肯定是不可见的。
如果落在绿色区域，表示这个版本是之前事务创建的，肯定是可见的。
如果落在黄色区域，存在以下两个情况：
若 row trx_id 在数组中，表示这个版本是由还没提交的事务生成的，不可见；
若 row trx_id 不在数组中，表示这个版本是已经提交了的事务生成的，可见。
row trx_id 在数组说明这个事务启动那一刻， row trx_id 所对应的事务是启动了但没有提交，该事务对该数据版本不可见。
现在我们来对如下三个事务进行分析（初始值为1，1）：
begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动。如果你想要马上启动一个事务，可以使用 start transaction with consistent snapshot 这个命令。
这里，我们不妨做如下假设：
- 事务 A 开始前，系统里面只有一个活跃事务 ID 是 99；
- 事务 A、B、C 的版本号分别是 100、101、102，且当前系统里只有这四个事务；
- 三个事务开始前，(1,1）这一行数据的 row trx_id 是 90。
这样，事务 A 的视图数组就是 [99,100], 事务 B 的视图数组是 [99,100,101], 事务 C 的视图数组是 [99,100,101,102]。
现在事务A来读数据，他的视图数组为[99,100],他的查询过程如下：
- 首先读数据都是从当前版本读起的，当前最新的数据版本是101，对应的数据为（1，3），由于101比100大，处于高水位，所以不可见。
- 接着就需要去找到上一个版本了，上一个版本是102，处于高水位，不可见；
- 又接着找上一个版本，终于找到了（1,1)，它的 row trx_id=90，比低水位小，处于绿色区域，可见。
所以事务A最终查询出来的数据是90。
下面我们对上诉分析用通俗的话翻译以下：
一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：
版本未提交，不可见；
版本已提交，但是是在视图创建后提交的，不可见；
版本已提交，而且是在视图创建前提交的，可见。
对于上面的例子，我们再来分析一下：
- 由于103版本是事务B更改的，在事务A查询的时候，这个事务还没有提交，所以不可见。
- 102版本是提交的，但是是在视图创建后提交的，不可见。
- 90版本是在视图数组创建之前提交的，可见。
# 更新逻辑
试想一个问题，在刚才例子中事务C更新了数据，现在事务B要更新数据，更新数据会进行一次数据查询，这个查询返回的 k 的值确实是 1。
但是，当它要去更新数据的时候，就不能再在历史版本上更新了，否则事务 C 的更新就丢失了。因此，事务 B 此时的 set k=k+1 是在（1,2）的基础上进行的操作。
这里有一条规则：更新数据都是先读后写的，而这个读，只能读当前的值，称为"当前读"。
因此，在更新的时候，当前读拿到的数据是 (1,2)，更新后生成了新版本的数据 (1,3)，这个新版本的 row trx_id 是 101。
所以，在执行事务 B 查询语句的时候，一看自己的版本号是 101，最新数据的版本号也是 101，是自己的更新，可以直接使用，所以查询得到的 k 的值是 3。
现在如果事务C不是马上提交：
现在的情况是事务C’更新之后并没有马上提交，在提交之前事务B发起了更新语句。由于两阶段锁协议事务C’是持有这一行数据的写锁，而事务B在更新之前会查询一下，属于当前读，必须要读最新版本，而且必须加锁，因此就被锁住了，必须等到事务 C’释放这个锁，才能继续它的当前读。
可重复读的核心就是一致性读（consistent read）；而事务更新数据的时候，只能用当前读。如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待。
读提交和可重复读的区别：
- 在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图；
- 在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图。
现在如果按照读提交的方式再来分析一下之前的例子：
对于事务A：
- （1，3）是最新版本，但是由于没有提交，不可见。
- （1，2）提交了，可见
所以A查询出来k的数值为2。
对于事务B：
- （1，3）是事务B自己更新的版本，可见
所以B查询出来k的数值为3。