再话可重复读事务
在之前我们说到了可重复读事务，由MVCC多版本控制来实现，接下来我们再来探讨一下事务的可重复读是怎么实现的。
强调：
- 在RR事务开启的时候，有begin/start transaction 启动的事务是在第一次查询的时候创建一致性视图。当我们用start transaction with cinsistent snapshot语句的时候将会在事务开启的时候创建一致性视图。
- 一致性视图并不会拷贝数据库的全部数据，因为有每一行都有它的版本号，事务开启的时候可会有一个递增的版本号，在之前我们提到，当事务修改行数据的时候，会有一个undo log记录当前数据，并且将事务的版本号赋给行版本。当我们需要计算出事务可见的状态的时候，就是通过undo log来推算出来的。innodb利用数据的多版本特性快速的创建了一致性视图。
- 当事务开始的时候，会创建一个事务数组用来保存已经启动但是还没有提交的活跃事务id，视图数组中的最小id称之为低水位线，最大的事务id+1称之为高水位线。
从图中可以看到，第一个有效更新是事务 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 查询语句的读数据流程是这样的：
这样执行下来，虽然期间这一行数据被修改过，但是事务 A 不论在什么时候查询，看到这
行数据的结果都是一致的，所以我们称之为一致性读。
这个判断规则是从代码逻辑直接转译过来的，但是正如你所见，用于人肉分析可见性很麻
烦。
所以，我来给你翻译一下。一个数据版本，对于一个事务视图来说，除了自己的更新总是可
见以外，有三种情况：
- 版本未提交，不可见；
- 版本已提交，但是是在视图创建后提交的，不可见；
- 版本已提交，而且是在视图创建前提交的，可见。
现在，我们用这个规则来判断图 4 中的查询结果，事务 A 的查询语句的视图数组是在事务A 启动的时候生成的，这时候：找到 (1,3) 的时候，判断出 row trx_id=101，比高水位大，处于红色区域，不可见；接着，找到上一个历史版本，一看 row trx_id=102，比高水位大，处于红色区域，不可见；再往前找，终于找到了（1,1)，它的 row trx_id=90，比低水位小，处于绿色区域，可见。你看，去掉数字对比后，只用时间先后顺序来判断，分析起来是不是轻松多了。所以，后面我们就都用这个规则来分析。
更新逻辑
前面说的一致性读并不对更新语句有效，当事务中的更新语句是，其看到的数据必须是当前的最新值，不然其他事务的操作就会被掩盖掉。更新数据的时候都是先读后写的，这个都就是当前读。除了update语句，我们也可以让select语句变成当前读。
select * from t where id=1 for update//写锁
select * from t where id =1 lock in share mode//读锁
一致性视图
在mysql中利用一致性视图来实现可重复读和读提交。对于读提交，每次查询操作都会更新视图数组。
事务的可重复读是怎么实现的？
事务的可重复读的核心是一致性读，一致性读是通过创建一致性视图和MVCC来实现的，而对于更新操作，只能用当前读。
