有如下表结构，并分别开启事务A,事务B和事务C。


mysql> CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `k` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into t(id, k) values(1,1),(2,2);

begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动。如果你想要马上启动一个事务，可以使用 start transaction with consistent snapshot 这个命令。

第一种启动方式，一致性视图是在执行第一个快照读语句时创建的；
第二种启动方式，一致性视图是在执行 start transaction with consistent snapshot 时创建的。

在MySQL中有两个视图，一个是通过create view创建的视图，另一个是MVCC中的一致性视图。

MVCC原理

在可重复读级别下，视图就是要事务启动的时候拍了个快照。

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

图中虚线框里是同一行数据的 4 个版本，当前最新版本是 V4，k 的值是 22，它是被 transaction id 为 25 的事务更新的，因此它的 row trx_id 也是 25

实际上，图 2 中的三个虚线箭头，就是 undo log；而 V1、V2、V3 并不是物理上真实存在的，而是每次需要的时候根据当前版本和 undo log 计算出来的。比如，需要 V2 的时候，就是通过 V4 依次执行 U3、U2 算出来。

按照可重复读的定义，一个事务启动的时候，能够看到所有已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可见。那这个是怎么实现的呢？

其实，InnoDB在事务启动的时候会创建一个数组，数组中的内容就是transaction_id。并按transaction_id的大小进行排序。

数组里面事务 ID 的最小值记为低水位，当前系统里面已经创建过的事务 ID 的最大值加 1 记为高水位。

这样，对于当前事务的启动瞬间来说，一个数据版本的 row trx_id，有以下几种可能：

如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的；

如果落在红色部分，表示这个版本是由将来启动的事务生成的，是肯定不可见的；

如果落在黄色部分，那就包括两种情况

a. 若 row trx_id 在数组中，表示这个版本是由还没提交的事务生成的，不可见；

b. 若 row trx_id 不在数组中，表示这个版本是已经提交了的事务生成的，可见。

案例分析

对于上述的事务A、B、C，有如下假设：

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

对于事务A来说：

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

更新逻辑

对于更新逻辑，与查询逻辑有点不一样。对于事务B,set k = k+1，它更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”（current read）。

这种情况下，事务B必须等到事务C1释放锁后才能继续。

事务的可重复读的能力是怎么实现的？

可重复读的核心就是一致性读（consistent read）；而事务更新数据的时候，只能用当前读。如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待

MySQL隔离级别笔记

MVCC原理

案例分析

更新逻辑

事务的可重复读的能力是怎么实现的？