摘要：Read Committed事務(wù)運行期間，只要別的事務(wù)修改數(shù)據(jù)并提交，即可讀到人家修改的數(shù)據(jù)，所以會有不可重復(fù)讀、幻讀問題。ReadView機制基于undo log版本鏈條實現(xiàn)的一套讀視圖機制，事務(wù)生成一個ReadView：若為事務(wù)自己更新的數(shù)據(jù)，自己可以讀到或在你生成ReadView之前提交的事務(wù)所修改的值，也可讀到但若你生成ReadView時，就已經(jīng)活躍的事務(wù)，但如果它在你生成Read...

ReadView機制基于undo log版本鏈條實現(xiàn)的一套讀視圖機制，事務(wù)生成一個ReadView：

• 若為事務(wù)自己更新的數(shù)據(jù)，自己可以讀到
• 或在你生成ReadView之前提交的事務(wù)所修改的值，也可讀到
• 但若你生成ReadView時，就已經(jīng)活躍的事務(wù)，但如果它在你生成ReadView之后修改的數(shù)據(jù)并提交了，此時你讀不到
• 或你生成ReadView以后再開啟的事務(wù)修改了數(shù)據(jù)，還提交了，也讀不到

所以上面那套機制就是ReadView的一個原理如何基于ReadView實現(xiàn)RC？核心設(shè)計：當(dāng)一個事務(wù)設(shè)置RC，他是每次發(fā)起查詢，都重新生成一個ReadView！

數(shù)據(jù)庫里有一行數(shù)據(jù)，是事務(wù)id=50的一個事務(wù)，很久以前就插入的，當(dāng)前活躍事務(wù)：

• 事務(wù)A（id=60）
• 事務(wù)B（id=70）

現(xiàn)在事務(wù)B發(fā)起update，更新這條數(shù)據(jù)為b，所以此時數(shù)據(jù)的trx_id會變?yōu)槭聞?wù)B的id=70，同時生成一條undo log：

這時，事務(wù)A要發(fā)起一次查詢操作，就會生成一個ReadView

這時事務(wù)A發(fā)起查詢，發(fā)現(xiàn)當(dāng)前這條數(shù)據(jù)的trx_id=70。即屬于ReadView的事務(wù)id范圍之間，說明是他生成ReadView之前就有這個活躍的事務(wù)，是這個事務(wù)修改了這條數(shù)據(jù)的值，但此時事務(wù)B還沒提交，所以ReadView的m_ids活躍事務(wù)列表里，有[60, 70]兩個id，此時根據(jù)ReadView機制，事務(wù)A無法查到事務(wù)B修改的值b。

接著就順著undo log版本鏈條往下查找，就會找到一個原始值，發(fā)現(xiàn)其trx_id是50，小于當(dāng)前ReadView里的min_trx_id，說明是他生成ReadView之前，就有一個事務(wù)插入了這個值并且早就提交了，因此可以查到這個原始值。

接著，假設(shè)事務(wù)B提交，提交了就說明事務(wù)B不會活躍于數(shù)據(jù)庫里了。事務(wù)A下次再查詢，就可以讀到事務(wù)B修改過的值了。那到底是怎么讓事務(wù)A能夠讀到提交的事務(wù)B修改過的值呢？

讓事務(wù)A下次發(fā)起查詢，再生成一個ReadView，數(shù)據(jù)庫內(nèi)活躍的事務(wù)只有事務(wù)A，因此：

• min_trx_id是60
• mac_trx_id是71
• m_ids=60，事務(wù)B的id=70不會出現(xiàn)在m_ids活躍事務(wù)列表

此時事務(wù)A再次基于這個ReadView去查詢，會發(fā)現(xiàn)這條數(shù)據(jù)的trx_id=70，雖然在ReadView的min_trx_id和max_trx_id范圍之間，但是此時并不在m_ids列表內(nèi)，說明事務(wù)B在生成本次ReadView之前就已提交。說明這次你查詢就可以查到事務(wù)B修改過的這個值了， 此時事務(wù)A就會查到值B。

到此這篇關(guān)于MySQL RC事務(wù)隔離的實現(xiàn)的文章就介紹到這了,更多相關(guān)MySQL RC事務(wù)隔離內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論