RC、RR的隔离级别是如何基于ReadView实现的？

一、Read Committed隔离级别是如何基于ReadView机制实现的？

首先我们的数据库里有一行数据，是事务id=50的一个事务之前就插入的，之后俩个事务：事务A（id=60），事务B（id=70）。事务B将这条数据修改为B，此时数据的trx_id=70，同时生成一条

undo log日志。roll_pointer指向trx_id=50的日志链。

这个时候，事务A发起一次查询动作，此时事务A会生成一个ReadVIew，ReadView里的min_trx_id=60，max_trx_id=70，creator_trx_id=60。

事务A查询这条数据的时候发现这条数据的trx_id=70，说明他生成ReadView之前就有这个活跃的事务，是这个事务修改了这套数据的值，但是此时事务B还没有提交事务，所以ReadVIew的m_ids货物事务列表中，是有[60，70]俩个id，所以此时根据ReadView的机制，此时事务A是无法查询 到事务B修改的值B。

接着，假设事务B此时提交了，好了，那么提交了就说明事务B不会活跃于数据库，是不是？可以的，大家一定记住，事务B现在提交了，那么按照RC隔离级别的定义，事务B此时一旦提交了，说明事务A下次查询，就可以读到事务B修改的值。

事务A再次查询的时候，生成的ReadView中min_trx_id=60，max_trx_id=71，但是m_ids列表中只有60，事务B的id=70不会出现在m_ids活跃事务列表中。

此时事务A再次基于这个ReadView去查询，会发现这条数据的trx_id=70，虽然在ReadView的min_trx_id和max_trx_id范围之间，但是此时并不在m_ids列表内，说明事务B在生成本次ReadView之前就已经提交了。所以此时事务A就可以查询到B值。

二、Read Committed隔离级别是如何基于ReadView机制实现的？

首先事务id=5插入一条数据，同时还有事务A（id=60），事务B（id=70）。事务A发起一个查询

动作，此时生成的ReadView中creator_trx_id=60，min_trx_id=60，max_trx_id=71，m_ids=[60,70]。

事务A基于这个ReadView去查这条数据，会发现这条数据的trx_id=50，是小于ReadView中min_trx_id的，说明事务A发起查询前，这个事务已经提交了，所以此时是可以查到这条原始数据的。

接着事务B更新这条数据的值为B，此时会修改trx_id=70，同事生成一个undo log，而且关键是事务B已经提交了，说明事务B已经结束了。

根据RC的经验，这时候的m_ids里面只有60了，那RR呢？RR中的m_ids是[60,70]。因为ReadView一旦生成了就不会改变了，此时虽然事务B已经结束了，但是事务A的ReadView中m_ids还是会有60,70。

接着事务A去查询数据的时候，发现此时数据的trx_id=70,70在ReadView的min_trx_id和max_trx_id范围区间，同时也在m_ids列表中。所以事务A还不能查询事务B修改的数据，因为事务A开启查询的时候，事务B还处于活动中，所以这个时候必须继续顺着指针往历史版本链条上去找。

接着事务A顺着指针找到下面一条数据trx_id=50，是小于ReadView的min_trx_id的，说明在他开启查询之前，就已经提交了这个事务，所以事务A是可以查询到这条数据的。

接着我们看幻读是如何解决的。假设事务A查询到1条数据。接着事务C插入了一条数据

，然后提交了事务，此时就有俩条数据了。接着事务A再次查询，此时会发现有俩条数据

，一条是原始数据，一条是事务C插入的一条数据，但是事务C插入数据的trx_id=80，这个80是大于ReadView的max_trx_id，说明是自己发起查询之后，事务C才启动的，所以此时这条数据是不能查询的。一次事务A本次查询的时候，只能查询到原始值这条数据。

借道友法力一用：

========================== stay hungry stay foolish =============================