MVCC如何实现

在可重复读隔离级别下，事务在启动时候就拍了个快照。
这个快照是基于整个数据库的。

那么如何实现这个快照呢？（一致性读）
首先每个事务都有唯一的事务ID，叫作transaction id。它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的。
每行数据也有多个版本的，每次事务更新数据的时候，都会生成一个新的数据版本，并且将transaction id赋值给这个数据版本的事务ID，记作row_trx_id。同时，旧的数据版本也要保留，并且在新的数据版本中，能够有信息直接拿到它。
也就是说，数据表中的一行数据，其实可能有多个版本，每个版本都有自己的row_id。

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

图上的U3、U2、U1就是undo log。V1、V2、V3其实并不是物理真实存在的，而是每次需要的时候根据当前版本和undo log计算出来的，V2，就是通过V4依次执行U3、U2算出来的。

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

因此InnoDB为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在活跃的所有事务ID。活跃指的是启动了但是还没有提交。

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

这个视图数组和高水位，就组成了当前事务的一致性视图（read-view）。

而数据版本的可见性规则，就是基于数据的row_trx_id和这个一致性视图的对比结果得到的。

这样，对应当前事务的启动瞬间，一个数据版本的row_trx_id，有一下几种可能。

1. 如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的。
2. 如果落在红色部分，表示这个版本是由将来的启动事务生成的，是不可见的
3. 如果落在黄色部分，那就包括两种情况。
   a.若row_trx_id在数组中，表示这个版本是由还没提交是事务生成的，不可见。
   b.若row_trx_id不在数组中，表示这个版本是已经提交的事务生成的，可见。

一致性读的另一种版本
事务启动瞬间：

1. 版本未提交，不可见
2. 版本已提交，但是是在视图创建之后提交的，不可见
3. 版本已提交，而且是在视图创建之前提交的，可见

更新逻辑（当前读）

更新数据都是先读后写的，而这个读，只能读取当前的值，称为当前读。

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

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

提交读的MVCC是如何实现的

逻辑，主要有以下区别：

• 在可重复读隔离剂级别下，只需要在事务开始的时候创建一致性视图，之后的事务里的其他查询都共用这个一致性视图。
• 在读提交隔离级别下，每个语句执行前都会重新算出一个视图。

总结

InnoDB的行数据有多个版本，每个数据版本都有自己的row_trx_id，每个事务或者语句有自己的一致性视图。普通查询语句是一致性读，一致性读会根据row_trx_id和一致性视图确定数据版本的可见性。

• 对于可重复读，查询只承认在事务启动前就提交完成的数据
• 对于提交读，查询只承认在语句启动前就已经提交完成的数据。

而当前读，总是读取已经提交完成的最新版本。