1目录
再谈 mvcc 举例整合事务隔离级别 事务可重复读实现 读提交、可重复读区别 MySQL8.0 官文事务
2继续
之前MySQL系列：事务隔离，如果是可重复读级别，事务 T启动时会创建一个试图read-view，之后事务 T 执行期间，即使有其他事务修改了数据，事务 T 看到的仍是和启动时看到的一样。也就是说一个可重复读级别执行事务，好像与世无争。
但，上一篇：MySQL系列：行锁、死锁 的时候有说到一个事务要更新一行，如果刚好有另外一个事务拥有这行行锁，它会被锁住且进入等待状态。
来个栗子：
mysql> CREATE TABLE `aaaqi` (
`id` int(11) NOT NULL,
`k` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into aaaqi(id, k) values(1,1),(2,2);
// 都是默认 autocommit=1。
begin/start transaction 命令并不是一个事务的起点，在执行到他们之后的第一个 innodb表的操作语句，事务才真正启动。
如果想要马上启动一个事务，可以使用 start transaction with consistent snapshot 这个命令。
第一种方式：一致性视图是在执行第一个快照语句时创建的；
第二种方式：一致性视图是在执行
start transaction with consistent snapshot时创建的。
上面栗子中事务 C 没有显示的使用begin/commit，表示这个 update 语句本身就是一个事务，语句完成的时候会自动提交。
事务 B 在更新了行之后查询；事务 A 在一个只读事务中查询，并且时间顺序上事务 B的查询之后。所以事务 B 查到的 k 的值是 3，而事务 A 查到的 k 值是 1，本文后面小节会详细分析结果。
在 MySQL 里，有两个“视图”的概念：
一个是 view。它是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是 create view ...，而它的查询方法与表一样。另一个是 InnoDB 在实现 MVCC时用到的一致性读视图，即consistent read view，用于支持RC(read commited，读提交)和RR(repeatable read，可重复读)隔离级别的实现。
在MySQL系列：事务隔离中有说过MVCC的实现逻辑，这里会换一个方式来说明。
3再谈 mvcc
在可重复读隔离级别下，事务在启动的时候就“拍了个快照”。这里这个快照是基于整个数据库的。
InnoDB 里面每个事务有一个唯一的事务 id，叫做transaction id。它是在事务开始时向 InnoDB 的事务系统申请的，按申请顺序严格递增。
而每行数据也都是有多个版本的。每次事务更新数据时，都会生成一个新的数据版本，并且把transaction id赋值给这个数据版本的事务 id，记为row trx_id。同时，旧数据版本要保留，并在新数据版本中，能够有信息可以直接拿到它。
也就是说，数据表中的一行记录，其实是可能有多个版本(row)，每个版本有自己的 row trx_id。
下图所示，是一个记录被多个事务连续更新后的状态。
图中虚线框里是同一行数据的 4 个版本，当前最新版本是 V4，k 的值是 22，它是被transaction id 为 25 的事务更新的，因此row trx_id也是 25。
语句的更新会生成undo log(回滚日志) ，实际上图中的3 个虚线箭头(U1、U2、U3那)就是undo log；而 v1、v2、v3 并不是物理上真实存在的，而是每次需要的时候根据当前版本和 undo log 计算出来的。比如，需要 v2 时，通过 v4 依次执行 U3、U2 算出来。
按照可重复读的定义，一个事务启动的时候，能够看到所有已经提交的事务结果。但是之后，这个事务执行期间，其它事务的更新怼它不可见。
简单点说，以我启动的时刻为准，如果一个数据版本是在我启动之前生成的，就认；如果是我启动之后才生成的，就不认，但必须找到它的上一个版本。
如果上一个版本也不可见，那就得继续往前找。还有，如果这个事务自己更新的数据，它自己还是要认的。
在实现上，innodb 为每个事务构造了一个数组，用来保存这个事务启动的瞬间，当前正在“活跃”的所有事务 id。“活跃”指，启动了但还没有提交。
数组里面事务 id 的最小值记为低水位，当前系统里面已经创建过的事务 id 的最大值加 1 记为高水位。
这个视图数组和高水位，就组成了当前事务的一致性视图(read-view)。
而数据版本的可见性规则，就是基于数据的 row trx_id 和这个一致性视图的对比结果得到的。
这个视图数组把所有的 row trx_id 分成了几种不同的情况。
这样，对于当前事务的启动瞬间来说，一个数据版本的 row trx_id,有以下几种可能：
如果落在绿色部分(不是绿箭头)，说明这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的。 如果落在紫色部分，说明这个版本是由将来启动的事务生成的，是肯定不可见的。 如果落在橙色部分，那就有两种情况： row trx_id在数组中，说明这个版本是由还没提交的事务生成的，不可见。row trx_id不在数组中，说明这个版本是已经提交了的事务生成的，可见。
上面图 A，如果有一个事务，它的低水位是 18，那么当它访问这一行数据时，就会从 v4 通过 u3 计算出 v3，所以在它看来，这一行的值是 11。
InnoDB 利用了“所有数据都有多个版本”的这个特性，实现了“秒级创建快照”的能力。
接下来，分析上面图 1 三个事务的结果。
假设：
事务 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]。
图中可以看到，第一个有效更新是事务 C，把数据从(1,1)改成了(1,2)，这个时候，这个数据的最新版本的row trx_id 是 102，而 90 这个版本就成了历史版本。
第二个有效更新的事务 B，把数据从(1,2)更新为(1,3)。这时，这个数据的最新版本 row trx_id是 101，而 102 又成为了历史版本。
在事务 A 查询的时候，其实事务 B 还没有提交，但是它生成的(1,3)这个版本已经变成当前版本了，但这个版本对事物 A 必须是不可见的，否则就变成脏读了。
现在事务 A 要来读数据了，它的视图数组是[99.100]。当然，读数据都是从当前版本读起的，所以，事务 A 的查询语句读数据流程如下：
找到(1,3)的时候，判断出 row trx_id=101，比高水位大，处于紫色区域，不可见；继续，找到上一个历史版本， row trx_id=102，比高水位大，处于紫色区域，不可见；再继续往前找，找到了(1,1)，它的 row trx_id=90，比低水位小，处于绿色区域，可见。
这样执行下来，虽然期间这行数据被修改过，但是事务 A 无论在什么时候查询，看到这行的数据的结果都是一致的，也就是一致性读。
一个数据版本，对于一个事务视图来说，除了自己更新总是可见以外，有三种情况：
版本未提交，不可见； 版本已提交，但是是在 视图创建后提交的，不可见；版本已提交，而且是在 视图创建前提交的，可见。
现在用这个规则来判断图 B 中的查询结果，事务 A 的查询语句的视图数组是在事务 A 启动的时候生成的，这时候：
(1,3) 还没提交，属于情况 1，不可见； (1,2) 虽然提交了，但是是在视图数组创建之后提交的，属于情况 2，不可见； (1,1) 是在视图数组创建之前提交的，可见。
4更新逻辑
上面事务 B 的 update 语句，如果按照一致性读，好像有问题。
如果事务 B 在更新之前查询一次数据，那么这个查询返回的 k 值确实是 1。
但是，当它要去更新数据的时候，就不能在历史版本上更新了，否则事务 C 的更新就会丢失，因此，事务 B 此时的 set k=k+1是在(1,2)的基础上进行操作的。
更新数据都是先读后写，而这个读，只能读当前的值，也就是“当前读”。
所以，在更新的时候，当前读拿到的数据是(1,2),更新后生成了新版本的数据(1,3)，这个新版本row trx_id 是 101。
在执行事务 B 查询语句的时候，一看自己的版本号是 101，最新数据的版本号也是 101，是自己的更新，可以直接使用，所以查询得到的 k 值是 3。-- 这里前面有说过，自己的修改是要认的。再加上修改是当前读（读到2）的修改，所以修改后的值就是3。
其实，除了 update 语句外，select 语句如果加锁，也是当前读。
所以，如果事务 A 的查询语句select * from aaaqi where id=1修改一下，加上lock in share mode 或 for update，也都可以读到版本号 101 的数据，返回的 k 值是 3。下面两个select 语句，就是分别加了读锁(S 锁，共享锁)和写锁(X 锁，排他锁)。
mysql> select k from t where id=1 lock in share mode;
mysql> select k from t where id=1 for update;
假设事务 C 不是马上提交的，而是变成了下面的事务 C，会发生什么？
事务 C 不同的是，更新后没有马上提交，在它提交之前，事务 B 的更新语句先发起了。前面有提到，虽然事务 C 还没有提交，但是(1,2)这个版本已经生成了，并且是当前的最新版本。
那么之前两阶段锁协议就要上场了，事务 C 没提交，也就是说(1，2)这个版本上的写锁还没有释放。而事务 B 是当前读，必须要读最新版本，而且必须加锁，因此就被锁住了，必须等到事务 C 释放这个锁，才能继续它的当前读。
到这里，一致性读、当前读、行锁就都串起来了。
5事务的可重复读实现
**可重复读的核心是一致性读；而事务更新数据的时候，只能用当前读。如果当前的记录的行锁被其它事务占用的话，就需要进入锁等待。 **
读提交的逻辑和可重复读的逻辑差不多，主要区别如下：
在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其它查询都共用这个一致性视图； 在读提交隔离级别下，每个语句执行前都会重新算出一个新的视图。
在读提交隔离级别下，事务 A 和事务 B 的查询语句查到的 k，分别是多少？
“start transaction with consistent snapshot；”的意思是从这个语句开始，创建一个持续整个事务的一致性快照。所以，在读提交隔离级别下，这个用法就没意义了，等效于普通的 start transaction。
下面是读提交时的状态图，可以看到这两个查询语句的创建视图数组的时机发生了变化，就是图中的read view框。这里用事务 C 的逻辑直接提交。
上图，事务 A 的查询语句的视图组是在执行这个语句的时候创建的，时序上(1,2)、(1,3)的生成时间都在创建这个视图数组的时刻之前。但是在这个时刻：
(1,3)还没提交，属于情况 1，不可见； (1,2) 提交了，属于情况 3，可见；
所以，这时事务 A 查询语句返回的是 k=2，事务 B 查询的结果 k=3。
MySQL8.0 事务官方文档：https://dev.mysql.com/doc/refman/8.0/en/sql-transactional-statements.html
