摘要：Read Committed事务运行期间，只要别的事务修改数据并提交，即可读到人家修改的数据，所以会有不可重复读、幻读问题。ReadView机制基于undo log版本链条实现的一套读视图机制，事务生成一个ReadView：若为事务自己更新的数据，自己可以读到或在你生成ReadView之前提交的事务所修改的值www.cppcns.com，也可读到但若你生成ReadView时，就已经活跃的事务，但如果它在你生成Read...

ReadView机制基于undo log版本链条实现的一套读视图机制，事务生成一个ReadView：

• 若为事务自己更新的数据，自己可以读到
• 或在你生成ReadView之前提交的事务所修改的值，也可读到
• 但若你生成ReadView时，就已经活跃的事务，但如果它在你生成ReadView之后修改的数据并提交了，此时你读不到
• 或你生成ReadView以后再开启的事务修改了数据，还提交了，也读不到

所以上面那套机制就是ReadView的一个原理如何基于ReadView实现RC？核心设计：当一个事务设置RC，他是每次发起查询，都重新生成一个ReadView！

数据库里有一行数据，是事务id=50的一个事务，很久以前就插入的，当前活跃事务：

• 事务A（id=60）
• 事务B（id=70）

现在事务B发起update，更新这条数据为b，所以编程客栈此时数据的trx_id会变为事务B的id=70，同时生成一条undo log：

这时，事务A要发起一次查询操作，就会生成一个ReadView

这时事务A发起查询，发现当前这条数据的trx_id=70。即属于ReadView的事务id范围之间，说明是他生成ReadView之前就有这个活跃的事务，是这个事务修改了这条数据的值www.cppcns.com，但此时事务B还没提交，所以ReadVi编程客栈ew的m_ids活跃事务列表里，有[60, 70]两个id，此时根据ReadView机制，事务A无法查到事务B修改的值b。

接着就顺着undo log版本链条往下查找，就会www.cppcns.com找到一个原始值，发现其trx_id是50，小于当前ReadView里的min_trx_id，说明是他生成ReadView之前，就有一个事务插入了这个值并且早就提交了，因此可以查到这个原始值。

接着，假设事务B提交，提交了就说明事务B不会活跃于数据库里了。事务A下次再查询，就可以读到事务B修改过的值了。那到底是怎么让事务A能够读到提交的事务B修改过的值呢？

让事务A下次发起查询，再生成一个ReadView，数据库内活跃的事务只有事务A，因此：

• min_trx_id是60
• mac_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之前就已提交。说明这次你查询就可以查到事务B修改过的这个值了， 此时事务A就会查到值B。

到此这篇关于mysql RC事务隔离的实现的文章就介绍到这了,更多相关MySQL RC事务隔离内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！