Intermediate and advanced test questions ": what is the implementation principle of mvcc?

Hide fields

In addition to our custom fields, each line of records , And the database is implicitly defined DB_TRX_ID,DB_ROLL_PTR,DB_ROW_ID Etc

• DB_TRX_ID：6 byte , Recently modified transactions id, Record the transaction that created the record or last modified the record id

• DB_ROLL_PTR：7 byte , rollback pointer , Point to the previous version of this record , Used for coordination undolog, Point to the previous old version

• DB_ROW_JD：6 byte , Hidden primary key , If the data table has no primary key , that innodb It will automatically generate a 6 Bytes of row_id

The record is shown in the figure ：

 

In the diagram above ,DB_ROW_ID Is the only implicit primary key generated by the database for this row by default ,DB_TRX_ID Is the transaction currently operating the record ID,DB_ROLL_PTR It's a rollback pointer , Used for coordination undo journal , Point to the previous old version

undo log

undolog This is called the rollback log , It means in progress insert,delete,update Log generated during operation to facilitate rollback

When doing insert During operation , Produced undolog The transaction only needs to be rolled back , And can be discarded immediately after the transaction is committed

When doing update and delete During operation , Produced undolog Not just when the transaction is rolled back , When reading snapshots, you also need , So you can't delete , Only if the log is not involved in snapshot read or transaction rollback , The corresponding log will be purge Thread unified cleaning （ When data is updated or deleted, it is only necessary to set the of old records deleted_bit, It's not really deleting outdated records , Because to save disk space ,innodb Specialized purge Thread to clear deleted_bit by true The record of , If a record of deleted_id by true, also DB_TRX_ID be relative to purge Thread read view so , Then this record must be able to be cleared ）.

So let's see undolog Generated record chain

（1） Suppose there is a transaction number 1 Insert a record into the table , Then the status of the row data is ：

 

（2） Suppose there is a second transaction number 2 Of the record name Make changes , Change it to lisi

In the transaction 2 When modifying the record data of this line , The database will put an exclusive lock on the row . Then copy that line of data to undolog in , As Old record , That is to say undolog There is a copy of the current row in . After copying , Modify the line name by lisi, And modify the transactions of hidden fields id For the current transaction 2 Of id, The rollback pointer points to copy to undolog In the copy record of . After the transaction is committed , Release the lock .

 

（3） Suppose there is a third transaction number 3 Of the record age Made modifications , Change it to 32

In the transaction 3 When modifying the data of this row , The database will put an exclusive lock on the row . Then copy that line of data to undolog in , As an old record , It is found that there is already undolog 了 , Then the latest old data is used as the header of the linked list , Inserted in the line of record undolog front . Modify the line age by 32 year , And modify the transactions of hidden fields id For the current transaction 3 Of id, The rollback pointer points to the just copied undolog Copy records of . Transaction submission , Release the lock

 

From the above series of figures , You can see , Modification of the same record by different transactions or the same transaction , Will cause the record to undolog Generate a record version linear table , That's the list ,undolog The head of the chain is the latest old record , The end of the chain is the earliest old record .

Read View

If you understand the above process , Well, you need to further understand read view The concept of .

Read View It is the read view produced when a transaction performs snapshot read operations , At the moment when the transaction executes snapshot reading , Will generate a snapshot of the current data system , Record and maintain the current active transactions of the system id, The transaction id The value is increasing .

Actually Read View The most important function of is to make visibility judgment , That is, when a transaction is performing snapshot reading , Create a Read View The view of , Take it as a condition to determine which version of data the current transaction can see , It is possible to read the latest data , It is also possible to read the current line of records undolog Data of a version in .

Read View The visibility algorithm followed is mainly in the latest record of the data to be modified DB_TRX_ID（ Current affairs id） out , With other active transactions of the system id To compare , If DB_TRX_ID Follow Read View The properties of , Not in line with visibility , Then pass DB_ROLL_PTR Roll back the pointer to get it out undolog Medium DB_TRX_ID compare , That is, traverse the... In the linked list DB_TRX_ID, Until we find something that meets the conditions DB_TRX_ID, This DB_TRX_ID The old record is the latest and old version of data that can be seen by the current transaction .

Read View The visibility rules for are as follows ：

The first thing to know is Read View Three global attributes in ：

• trx_list: A list of values , Used for maintenance Read View Generate the transaction that the system is active at the moment ID（1,2,3）

• up_limit_id: Record trx_list Transactions in the list ID The smallest ID（1）

• low_limit_id:Read View Generate the next transaction that the system has not yet allocated ID,（4）

The specific comparison rules are as follows ：

• Compare first DB_TRX_ID < up_limit_id, If it is less than , Then the current transaction can see DB_TRX_ID Records , If it is greater than or equal to, go to the next judgment

• Then judge DB_TRX_ID >= low_limit_id, If it is greater than or equal to, it means DB_TRX_ID The record is in Read View It only appears after generation , Then it must not be visible to the current transaction , If it is less than , Then go to the next step to judge

• Judge DB_TRX_ID Is in an active transaction , If in , On behalf of Read View Generation time , This transaction is still active , Not yet commit, Modified data , The current transaction is also invisible , If not , It means that this transaction is in Read View It started before the generation commit, So the result of the modification can be seen

MVCC The overall processing flow of

Suppose there are four transactions executing at the same time , As shown in the figure below ：

From the above table , We can see , When a transaction 2 A snapshot read was performed on a row of data , The database generates a Read View View , You can see the business 1 And transaction 3 Still active , Business 4 In the transaction 2 Read the snapshot the moment before the update was submitted , therefore , stay Read View The current active transactions of the system are recorded in 1,3, Maintain in a list . And you can see that up_limit_id The value of is 1, and low_limit_id by 5, As shown in the figure below ：

 

In the above example , Only business 4 The line record has been modified , And in business 2 Before snapshot reading , Just commit the transaction , Therefore, the current data of this line undolog As shown below ：

 

When a transaction 2 The record in this row is read in the snapshot , I'll take the record of the line DB_TRX_ID Go with up_limit_id,lower_limit_id Compare with the list of active transactions , Interpretation services 2 You can see the version of the record in this line .

The specific process is as follows ： Take the transaction recorded in this line first ID（4） Go with Read View Medium up_limit_id Comparison , Judge whether it is less than , Through comparison, it is found that it is not less than , So it doesn't meet the conditions , Continue to judge 4 Greater than or equal to low_limit_id, Through comparison, it is found that it is not greater than , So it doesn't meet the conditions , Judge transactions 4 Whether to deal with trx_list In the list , Not found in the list again , Then meet the visibility condition , So the business 4 The latest results submitted after modification will affect the transaction 2 The snapshot of is visible , therefore , Business 2 The latest data record read is a transaction 4 Submitted version , And the business 4 The submitted version is also the latest version of the global perspective . As shown in the figure below ：

 

When the above contents are understood , Then you should be able to figure out the relationship between these core concepts , Let's talk about the next snapshot with different levels of isolation .

RC、RR Below the level of InnoDB What's the difference between snapshot reading ？

because Read View The timing is different , As a result RC、RR The results of snapshot reading are different at different levels

（1） stay RR The first snapshot read of a record by a transaction at level will create a snapshot, that is Read View, Record other active transactions in the current system , After that, when calling snapshot read , Or the same Read View, So as long as the current transaction has used snapshot read before other transactions commit updates , Then all subsequent snapshot reads use the same Read View, So it's not visible for later changes

（2） stay RR Below grade , Snapshot read generation Read View when ,Read View A snapshot of all other activities and transactions at this time will be recorded , Changes to these transactions are invisible to the current transaction , And earlier than Read View The changes made by the created office are visible

（3） stay RC Below grade , Transaction , Each snapshot read generates a new snapshot and Read View, This is where we are RC You can see the reasons for the updates committed by other transactions in the transactions below the transaction level .

summary ： stay RC Under isolation level , Every snapshot read generates and gets the latest Read View, And in the RR Under isolation level , The first snapshot read in the same transaction is created Read View, The subsequent snapshot reads all capture the same Read View.