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已提交，這意味著它不再是資料庫中的活躍事務。事務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事務隔離的詳細內容。更多資訊請關注PHP中文網其他相關文章！