MySQL transaction concurrency and mvcc mechanism

MySQL Transaction concurrency and MVCC Mechanism

Several problems of transaction concurrency

1. Dirty reading ( Read uncommitted data )

• Dirty reads refer to transactions that read uncommitted data from other transactions
• Take a chestnut
  

Business A Read... In the table name, Business B Change Zhang San in the table to "Zhang Laosan" , Suppose at this time the transaction A It reads name For Zhang Laosan , But at the end of the day B The data is rolled back for other reasons , In the database table name For Zhang San , Then there is a problem , Business A The data read is inconsistent with the data in the database table . And the reason for the data change is the transaction A I don't know

2. It can't be read repeatedly ( In the case of concurrent updates )

• Non repeatable read refers to the problem of inconsistent query in the same transaction
• Take a chestnut
  

Business A First query the personnel name in the database , After that, I will process other data , After that, the contents of the initial query are repeated , The transaction A The expectation should be that the results of the two queries should be consistent , Because business A When processing other data , No modification has been made to the queried data
But the problem is in business A When processing other data , Business B On business A The queried data has been updated and submitted , The transaction A And transaction B In the case of concurrency , The results of the two queries are inconsistent
But in practice, in theory, we do things A The data is not updated , So in business A Before submitting , No matter how many times the data is queried, it should be consistent , This theoretical situation is called repeatable
The situation that occurs concurrently above is called unrepeatable reading
The data read before and after the same transaction is inconsistent , As a result, our procedures are unpredictable and uncontrollable , This is the harm of non - repeatable reading

3. Fantasy reading ( Concurrent addition , Delete the operation that causes the total amount of data to change )

• Unreal reading is a mistake in which the amount of data changes before and after , Users have unpredictable problems
• Take a chestnut

In this case , Business A First, the database table is queried and a piece of data is found , After deleting the data , Business B Insert a piece of data into the database table , Business A It's not submitted yet , When a transaction A Query the data collection of the database table again , The expected result should be null data , But what the hell is this Li Si who comes out of thin air , This is the unreal reading problem that occurs when these two transactions are concurrent

Transaction isolation level

among MySQL The default transaction isolation level is the third : Repeatable , The special thing to remember is , It is often said that the repeatable read transaction isolation level can avoid dirty reads and non repeatable reads , But unreal reading can't be avoided , But in fact, if our database uses InnoDB There is no unreal reading in the storage engine .

Get and set the transaction isolation level

• In fact, it is generally unnecessary to set , Use the default , because MySQL5.1 After that, the default is InnoDB Storage engine , The default transaction isolation level is RR, It can avoid three kinds of concurrent transaction problems
  
• Why? InnoDB Storage engine in RR Unreal reading can also be avoided under the transaction isolation level ? This is about this MVCC Mechanism

MVCC Mechanism

Write it at the front

stay MySQL Of InnoDB Under the storage engine RC and RR Transaction isolation levels are based on this MVCC( Multi version concurrency control ) Controlling concurrent transactions
And then this MVCC Based on this " Data version " Access to concurrent transactions

Sample analysis

There are four things ABCD The first three transactions perform operations on the table name Fields to modify
Business D The operation is to query the data , But look at things carefully D The location of the query is still special , The first query is in the transaction A Post commit transaction B Before submitting , The second time the data is queried is in the transaction B After commit, in the transaction C Before submitting

• Respectively in RR Isolation level and RC Analyze the data read from the next two queries at the isolation level
  RR Under isolation level

RR The isolation level is repeatable , This means that the data read in the whole transaction is consistent. Obviously, the data obtained from the first query and the second query are consistent , namely name= Zhang San

RC Under isolation level

because RC Yes, I have submitted , As long as other transactions commit data , I will read , So actually, in the end RC The data read twice under the isolation level are : for the first time : Zhang San The second time : Zhang Xiaosan
Obvious RC The problem with the isolation level is that it is not repeatable

Analyze the phenomenon

be based on UNDO_LOG Version chain of

• UNDO_LOG It's a rollback log , While we are doing business , Only adding rollback logs , When our transaction fails to execute, we need to execute rollback Restore can only be performed when the operation is rolled back . Its principle is to organize in a chain way .
  
• The data in the top row is the current data of this field in our database , And then it was done update The transaction number of the statement is TRX_ID = 3
• Additional additional fields 1:TRX_ID Which transaction is the result of executing this version of data , Just record this transaction id
• Add extra fields 2:DB_ROLL_PTR: Pointer information , It points to the data of the last version change
• According to this table, we can clearly know that the data in the original table is zhangsanfeng ( hypothesis ), Then after three updates, it was updated to Zhang Laosan , Every data is transacted ID Identify as version
• UNDO_LOG What if it is deleted ? Intermediate data has been deleted UNDO_LOG The version chain is broken ?

UNDO_LOG The version chain is not deleted immediately ,MySQL Ensure that the version data link is no longer referenced before deleting , So in addition to some uncontrollable factors , General data are relatively complete

ReadView

• ReadView yes " Read the snapshot "SQL Execution time MVCC The basis for extracting data
• So using MVCC The premise of the mechanism is snapshot read , This is also InnoDB Under the storage engine RR An implementation of the transaction isolation level
• If the reading method is not snapshot reading but current reading , Then the implementation mechanism is not MVCC Instead of the mechanism, the locking method is used , Row lock and clearance lock are added

Snapshot read and current read

• Read the snapshot : Is the most common select Inquire about SQL A statement is a snapshot read
• The current reading : Refers to the way data is read when the following statements are executed :

insert into ...
update ...
delete ...
select ... for update
#  A write lock is added to the current 
select ...lock in share mode

ReadView data structure

• ReadView It is a data access structure , It contains 4 A field
  

Read submitted (RC) scenario

A new snapshot is generated each time a snapshot read is performed ReadView

• Generated by the first snapshot read readview As you can see from the diagram, the transaction 2,3,4 Not committed yet, so the current active transaction id:m_ids={2,3,4}, Minimum active transaction id:min_trx_id=2, Preallocated transactions id:max_trx_id = 5 ( Because it is the current maximum active transaction id + 1 So is 4 + 1 = 5), Current transaction creator id:creator_trx_id = 4
• Generated by the second snapshot read readview Same logic as the first analysis

Version chain data access rules

Version chain data access rules :

1. Judge the current transaction id be equal to creator_trx_id(4) Do you ? The establishment indicates that the data is changed by the transaction itself , You can visit .
2. Judge trx_id < min_trx_id(2) ? The establishment indicates that the data has been submitted , You can visit .
3. Judge trx_id > max_trx_id(5) ? If established, it means that the transaction is in readview Only after generation , Access not allowed .
4. Judge min_trx_id(2) <= trx_id <= max_trx_id(5), Established in m_ids Compare the data , If it does not exist, it means that the data has been submitted , You can visit .
   Give Way undo_log The versions in the version chain are brought into this rule from childhood to school to judge and find the first accessible data .

• For the first time readview

This snapshot can be read in trx_id = 1 In this version , Satisfy trx_id < min_trx_id(2) It indicates that the data has been submitted and can be accessed, so the data queried by the first query statement is Zhang San .

• The second generated snapshot reads

This snapshot can be read in trx_id = 2 The second rule is met trx_id < min_trx_id(3) Indicates that the data has been submitted , The data read is zhangxiaosan !!! There is a phenomenon of non repetition

Repeatable (RR) Scene

• Generated only on the first snapshot read ReadView, Subsequent snapshot reads reuse this ReadView( But there are exceptions )
  
• So in this case , Version chain does not change ,ReadView unchanged , Then the results of the two readings must be the same
• RR Use... At level MVCC Can you avoid unreal reading ? Yes, but not all !

When the snapshot is read continuously for many times ,ReadView There will be reuse , No unreal reading problem
But here's the thing : When there is a current read between two snapshot reads ,ReadView Will regenerate , Cause unreal reading