MySQL如何實現RC事務隔離

這篇文章給大家分享的是有關MySQL如何實現RC事務隔離的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

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之前就有這個活躍的事務，是這個事務修改了這條數據的值，但此時事務B還沒提交，所以ReadView的m_ids活躍事務列表里，有[60, 70]兩個id，此時根據ReadView機制，事務A無法查到事務B修改的值b。

接著就順著undo log版本鏈條往下查找，就會找到一個原始值，發現其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事務隔離”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！