How MySQL implements the RC transaction isolation level

Abstract ：Read Committed, During the transaction , As long as other transactions modify the data and submit , You can read the data modified by others , So there will be non repeatable 、 The problem of unreal reading .

This article is shared from Huawei cloud community 《MySQL RC Implementation of transaction isolation level 》, author ： JavaEdge .

Read Committed, During the transaction , As long as other transactions modify the data and submit , You can read the data modified by others , So there will be non repeatable 、 The problem of unreal reading .

ReadView The mechanism is based on undo log A set of view reading mechanism implemented by version chain , The transaction generates a ReadView：

• If the data is updated for the transaction itself , I can read
• Or when you generate ReadView The value modified by the previously submitted transaction , Also readable
• But if you generate ReadView when , It's already active , But if it's in your generation ReadView Then modified the data and submitted , You can't read
• Or you generate ReadView The transaction started later modifies the data , Also submitted , I can't read

So the above mechanism is ReadView How a principle of is based on ReadView Realization RC？ Core design ： When a transaction is set RC, Every time he makes a query , Regenerate a ReadView！

There is a row of data in the database , It's a business id=50 A business of , Inserted a long time ago , Currently active transactions ：

• Business A（id=60）
• Business B（id=70）

Now business B launch update, Update this data to b, So at this time, the data trx_id Will become a business B Of id=70, At the same time, a undo log：

At this time , Business A To initiate a query operation , It will generate a ReadView

When the transaction A Initiate a query , Find the current data trx_id=70. Belong to ReadView The business of id Between ranges , It means that he generated ReadView There was this active business before , It is this transaction that modifies the value of this data , But at this point the business B It hasn't been submitted yet , therefore ReadView Of m_ids In the active transaction list , Yes [60, 70] Two id, At this point, according to ReadView Mechanism , Business A Cannot find transaction B Modified value b.

Then follow it undo log Look down the version chain , You'll find an original value , Found that the trx_id yes 50, Less than the present ReadView Inside min_trx_id, It means that he generated ReadView Before , There is a transaction that inserts this value and has already committed , So you can find the original value .

next , What if B Submit , When submitted, the transaction will be explained B Will not be active in the database . Business A Check again next time , You can read the transaction B The modified value . How on earth does that make things A Be able to read the submitted transaction B The modified value ？

Make the transaction A Next time you initiate a query , Regenerate into one ReadView, The only active transactions in the database are transactions A, therefore ：

• min_trx_id yes 60
• mac_trx_id yes 71
• m_ids=60, Business B Of id=70 Will not appear in m_ids Active transaction list

At this point, the transaction A Again, based on this ReadView Go to query , You'll find this data trx_id=70, Although in ReadView Of min_trx_id and max_trx_id Between ranges , But not at this time m_ids In the list , Explain the business B When generating this ReadView Submitted before . Explain that you can find the transaction this time B The modified value , At this point, the transaction A You'll find the value B.

 

Click to follow , The first time to learn about Huawei's new cloud technology ~