102是read-view的max_id，同样也会落在min_id<=trx_id<=max_id这个区间，但是跟之前不同的是事务102是没有在数组中的，表示这个版本事务已经提交了所以是可见的
最后返回的是 niuniu
案例三为了让大家体验一下可重复读级别生成的read-view是根据在同一事务中第一条快照读产生的，再来看一个案例
此时的事务ID101也再对数据更新两次，然后在进行查询看一下会返回什么值
经过案例一、案例二的熟悉现在对undo log的版本链和对比规则已经有了一定的了解了吧！
案例三就不在那么详细的说明了。
此时的版本链如下
此时的read-view依然为[100,101],102。
那么首先会根据事务101去版本链对比，事务101和事务100都会落在min_id<=trx_id<=max_id这个区间，并且还都在数组中，所以数据是不可见的。
那么继续往版本链中寻找就会遇到事务102，这个是最大的事务ID并且不在数组中，所以是可见的。
于是最终的返回结果还是niuniu。
案例四可以看到个案例三的图不同的是新增了一个查询语句，那么假设这俩条语句执行的时间都是一致的，它们返回的结果会相同吗？
案例三查询到的值为niuniu
其实现在版本链跟案例三也是一致的
那么来梳理一下寻找过程
首先这里的read-view发生了变化，此时的read-view为[101],102
拿着当前的事务ID101跟版本链规则进行对比，落盘在min_id<=trx_id<=max_id，并且在数组中，则数据不可见
然后进入版本链，找到下一个数据的事务 ID，还是101，与上一个一致
接下来是事务ID100
事务ID100是落在trx_id<min_id，表示此版本是已经提交的事务生成的，由于事务已经提交所以数据是可见的