MySQL mvcc multi version concurrency control

One 、MVCC The concept of

MVCC It's multi version concurrency control （Multi-Version Concurrency Control, abbreviation MVCC）, yes MySQL Based on optimistic lock theory to achieve isolation level , Used to implement the isolation level of committed reads and repeatable reads , Also known as multi version database .MVCC The mechanism will generate a consistent data snapshot at the time point of data request （Snapshot）, And use this snapshot to provide a certain level （ Statement level or transaction level ） Consistent read of . From the user's point of view , It seems that the database can provide multiple versions of the same data （ System version number and transaction version number ）.
MVCC In multi version concurrency control , There are two types of read operations ：

1. Read the snapshot （ Unlocked read ）： Read the visible version of the record , Don't lock it . Such as select All I do is snapshot reading , Will have commit Generate a snapshot of the data （ This prevents non repeatable reading ）
2. The current reading ： The latest version of the record is read , And return the current read record . Such as insert,delete,update,select…lock in share mode/for update These operations , They all read the latest data .
   MVCC： Each line of record actually has multiple versions , The records of each version are in addition to the data itself , Added other fields （DB_ROW_ID、DB_TRX_ID、DB_ROLL_PTR）

stay Read committed Isolation level , Every time select Regenerate snapshots when querying （Read View）
stay Repeatable Isolation level , For the first time select When inquiring , Generate a snapshot of the global nature of the current transaction （Read View）, also Generate a snapshot only once

Snapshot content reading principle ：

• Version not available commit, Unable to read generated snapshot
• Version already commit, But after the snapshot is created , Can't read
• Version already commit, Create a snapshot before committing it , Can read
• Own updates in the current transaction , You can read

Two 、MVCC For committed read isolation level

1. To solve the dirty read

Set the isolation level to committed read and open transaction


You can see that the committed read solves the dirty read problem . Whether committed or repeatable , as long as select, Data snapshots will be generated , In the future, the data on the snapshot will be queried , Will not check the latest data , This is also known as an unlocked read , High efficiency , Unlike serialization , Both of them use locks to do concurrent and mutually exclusive transactions , The non lock reads are all operations performed on the snapshot .

At the committed read isolation level , every time select Will generate a new data snapshot , When a transaction 1 When making changes , Business 2 Go again select, Regenerate data snapshot （ It may be the same as the previous snapshot ）, However The premise of generating a new data snapshot is that the new data has been correctly used by the transaction commit,prepare State data will not appear in the snapshot

The data are 2 States ：prepare（ When not submitted ） and commit（ Has been submitted ）

Business 2 The second time select When , Due to transaction 1 did not commit The new data （ The data is in prepare state ）, When the data snapshot is generated again , The resulting data snapshot is still undo log The linked list of the rollback log points to the old data , This solves the dirty reading problem

However , Non repeatable reads will still occur at the committed read isolation level （ Two queries , The data content obtained is different , It belongs to the range of correct reading ）

2. Can't solve the problem of unrepeatable reading

Committed reads do not prevent non repeatable reads from occurring , Business 2 for the first time select When this data , Business 1 It hasn't been modified yet , therefore MVCC The generated snapshot read is a snapshot read generated from the original data , But the business 1 Now this data is changed and normal commit, Meet the basic requirements for generating data snapshots , At this point, the transaction 2 also select This data , every time select Will produce a new snapshot , This time, we will take a snapshot of the new data .

3. Can't solve unreal reading

Rollback and start the transaction

It is found that the amount of data queried is different under the same conditions , There's unreal reading , analysis ：

At this point, the transaction 2 Go again select * from user where age=16; First, generate a data snapshot , Take pictures of the data first, as shown in the figure below ：

Then find out from the inside age=16 The record of

Why can a transaction show the submitted data added by another transaction that meets the same query criteria in real time , This led to unreal reading of our affairs ？

Because every time select Will regenerate a new data snapshot , Other transactions add data with the same query criteria as the current transaction , And succeeded commit Submit , Causes the current transaction to query again with the same criteria , More data ！

3、 ... and 、MVCC For repeatable read isolation level

1. To solve the dirty read

prepare Status data will not appear on the data snapshot , Yes commit The submitted data generates a data snapshot , Then query on the data snapshot . For the same reason that the read analysis has been submitted .

2. Solve the problem of non repeatable reading

Repeatable for the first time select Generate data snapshot , And only once .

Set the repeatable read isolation level , Rollback and start two transactions

Business 2 for the first time select Data snapshots are generated , Because at the repeatable read level , Later select Will not generate data snapshots

The resulting data snapshots are as follows ：

Business 1update, then commit

update in the future , The table is as follows ：

Our business 2 Again select id=12 The data of , It was the first time select Take photos and check the data , Unrepeatable reads resolved .

If the transaction 2 In the transaction 1 No... Before updating the data select too , Then execute after the update select Data snapshots will be generated , You can find the updated data .

3. Can't completely solve unreal reading

First, check the data of the table

Rollback and start the transaction


Business 1 The generated snapshot is as follows ：

Business 2 for the first time select There are two pieces of data , Business 1 insert after , Business 2 Again select Still two , It seems to solve the unreal reading , In fact, it is only a partial solution （ It doesn't completely solve fantasy reading ）

Let's take a look at why it partially solves unreal reading

Business 1 insert then commit after , The data of the table should be like this

At this point, the transaction 2update

You can see update eureka id=24 The data of , This proves update What you do is read the current （ Read the latest commit State data ）, Instead of snapshot reading , Because there is no... In the snapshot id=24 The data of .

Actually 1000 It's a business 1 Of ID,2000 It's a business 2 Of ID

You can see your own transaction changes in the current transaction 、 Updated data .
When a transaction 2 Again select When , You can see that id=24 The data of the , That's what happened .

So at the repeatable read level , The problem of unreal reading is not completely solved