之前已经转载过几篇相关的文章，此次基于mysql 5.7 版本，从测试和源码角度解释一下RR,RC级别为什么看到的数据不一样
先补充一下基础知识
基本知识
假设对于多版本(MVCC)的基础知识，有所了解。InnoDB为了实现多版本的一致读，采用的是基于回滚段的协议。
行结构
InnoDB表数据的组织方式为主键聚簇索引。由于采用索引组织表结构，记录的ROWID是可变的(索引页分裂的时候，Structure Modification Operation，SMO)，因此二级索引中采用的是(索引键值, 主键键值)的组合来唯一确定一条记录。
无论是聚簇索引，还是二级索引，其每条记录都包含了一个DELETED BIT位，用于标识该记录是否是删除记录。除此之外，聚簇索引记录还有两个系统列：DATA_TRX_ID，DATA_ROLL_PTR。DATA _TRX_ID表示产生当前记录项的事务ID；
DATA _ROLL_PTR指向当前记录项的undo信息。
开启4个mysql客户端，client1 用来查看数据情况 , client2,client3,client4 更新数据
表结构
所有client 启动事务
执行 show engine innodb status\G ， 观察目前的事务信息
这里可以看到目前没有任何活动事务(select 不产生任何活动事务，只有insert ,update,delete 才会产生活动事务)
我们先在client2 执行一个insert sql,然后再在client1 看事务信息
我们可以看到client2 产生了12654 的活动事务, 我们继续再client3执行sql
client3 产生了一个12659的事务
我们从截图的角度看这2个事务
12659 -- 这是物理位置比较高的事务, mysql 本身里有专有名词叫 low_limit_id ,高水位
12654 --这是物理位置比较低的事务, up_limit_id ，低水位
接下来我们在client1 执行select查询
client2,client3还没有提交，这时候client1 只能获取到以前的旧数据
这时候client2,client3提交，再在client1查询
重点来了，这时候mysql产生了一份快照,这里叫read_view, 快照的结构是
read_view->creator_trx_id = 当前client1的事务id;
read_view->up_limit_id = 12654;
read_view->low_limit_id = 12659;
read_view->trx_ids = [12654,12659];
read_view->m_trx_ids = 2;
接下来，我们在client4执行insert操作，并马上commit提交，然后再在client1执行select查询
我们可以看到client4的修改虽然已经提交，但是client1还是看不到这个变化，那是因为:
low_limit_id; /* 索引数据事务号 DATA_TRX_ID >= low_limit_id的记录，对于当前Read View都是不可见的 */
up_limit_id; /* 索引数据事务号 DATA_TRX_ID< up_limit_id ，对于当前Read View都是可见的 */
刚才client4修改的时候产生的事务id是比12659还要大的一个数字, 没有查看，不知道具体数字，我们假设是12700这个数字
当产生read-view的时候, low_limit_id 是 12659,up_limit_id 是12654, 12700>12659 & 12654, 所以这些12654,12659对于那个read-view来说是看不见的
如果在client1 select 产生read-view 之前就执行client4的修改(和提交, 这时候client4的事务id, 我们假设就是一个比12654小的数字，如12600),12600<12654, 所以client4的修改对于当前read-view就是可视的
我们看看源码 read0types.h
那为什么事务隔离级别是RC级别的时候，重复上面的操作步骤， client1在client2,client3提交后select 的时候，就能马上查询到修改
我们看源码
ha_innodb.cc的ha_innobase::external_lock方法里
在RC级别的时候，每次都会关闭read-view并产生一份新的