Underlying principle of mvcc

Mysql The nature of transactions

Mysql InnoDB engine , There are four characteristics of transactions ACID（atomicity, consistency, isolation, durability）

Transactions are atomic units of work that can be committed or rolled back , Atomicity means , When there are multiple operations in a transaction that cause changes to database data , Or when the transaction is committed, it is all successful , Or when the transaction is rolled back, it is all unsuccessful

After the transaction is committed or rolled back , The database always maintains a consistent state . For example, the update operation between multiple tables , Query related data in multiple tables after transaction submission , They should all be new values ; Or after the transaction is rolled back , It's all old value . There should be no mixed state . for instance ,A The warehouse sends a piece of material to B Warehouse , After the transaction is committed ,A The inventory of relevant materials in the warehouse should be less 1,B There should be more relevant materials in the warehouse 1（ The so-called new value ）; And if the transaction rolls back ,A、B The inventory of warehouse related materials should be the original quantity （ The so-called old value ）. Should not exist ,A Few warehouses 1,B The same number of warehouses （ Mixed state ）

When multiple transactions are in progress , They're isolated from each other . Transactions cannot interact , Or view the uncommitted data of other transactions . Officials suggest experienced users to adjust the level of transaction isolation , Without causing the interaction between transactions , With less isolation , In exchange for higher performance and concurrency

Once submitted successfully , The end result of the transaction should be durable , Should not be affected by power failure 、 Software crash or other potential conditions . Persistence usually involves writing to disk storage , With a certain amount of redundancy , To prevent power failure or software crash during write operations .（ Use InnoDB engine , Double write caching is helpful for persistence ）

Atomicity is caused by undo log Ensure that the , Persistence is caused by redo log Ensure that the , Isolation is caused by MVCC Or the lock mechanism guarantees , Persistence is guaranteed by the above features .

Isolation level of isolation

The isolation level is when multiple transactions are modified or queried at the same time , For balancing performance 、 reliability 、 A setting of consistency and repeatability .

Sort from the highest level of isolation , In turn, is ： Serialization SERIALIZABLE, Repeatable REPEATABLE READ, Read submitted READ COMMITTED, Read uncommitted READ UNCOMMITTED

InnoDB The default isolation level for is ： Repeatable

Isolation level and corresponding table of related problems

	Dirty reading	It can't be read repeatedly	Fantasy reading
Read uncommitted	√	√	√
Read submitted	×	√	√
Repeatable	×	×	√
Serialization	×	×	×

Isolation problem practice

Dirty reading ： Read the uncommitted records of other transactions

 

It can't be read repeatedly ： The same A In business , Read twice , Inconsistent results , Because I read B Records after transaction submission

 

Fantasy reading ： The official interpretation is , A row of records appears in the result set of the query , But not in the early query result set . in other words , When the isolation level is set to repeatable reading ,A The transaction does not commit , Same query （ Read the snapshot ）, Run multiple times , The result set will not change . But in A Before the transaction is committed ,B The transaction performs the operation of inserting data , also B The transaction was also committed , Although it will not affect A Snapshot read results within a transaction , But at this time, the database actually has id by 6 This data , There will be the following two phenomena ：

1、 Perform the same sql：insert into score value(5," Qian Xiaoliu ",80), A primary key conflict exception will be reported , Some people say that this is also a phenomenon of unreal reading , There are only four pieces of data , Why does inserting Article 5 report primary key conflicts ？

2、 perform select * from score for update, data 6 Appear in the A Query result set of transaction , But it does not appear in the early query result set . This is the official interpretation of the unreal reading line （ That is, there are more id=6 This business ）

therefore , Fantasy reading emphasizes , Under the isolation level of repeatable reads , Although the same snapshot read can be run within a transaction sql Find consistent results , But it can't limit the addition of data by other transactions , As long as data with the same primary key is added, a primary key conflict exception will be reported , Or you can see the problem by using the current reading ,MySQL In addition to ordinary queries （select * from xx） It's snapshot reading , Others are The current reading , such as update、insert、delete, Before these statements are executed, the latest version of data will be queried , Then do the next step .

in addition ,select * from score for update This query statement is the current read , Read the latest data every time .

 

What is? MVCC？

MVCC It's multi version concurrency control （multiversion concurrency control） Abbreviation , This technology allows InnoDB Transactions perform consistent read operations .

MVCC How to apply it to different isolation levels ？

What is? Read View？

Definition ： yes InnoDB Of MVCC An internal snapshot used by the mechanism

appearance ： Some things （ Depends on their isolation level ） You can see the business （ perhaps sql sentence ） Data value at startup

Using range ： Repeatable 、 Read submitted 、 Read uncommitted three isolation levels are useful Read View

InnoDB Three fields are added to each row of records in the database ：

DB_TRX_ID： The transaction ID of the latest modified or newly added data of this bank

DB_ROLL_PTR： rollback pointer , Yes undo log Record

DB_ROW_ID： With the insertion of new line records , Monotonically increasing row ID , When there is no primary key , Just use DB_ROW_ID Build index .

Read View stay mysql In the source code is a class, There are multiple fields , The following four are the core fields

 

m_low_limit_id：

The read should not see any transaction with trx id >= this value.

In other words, this is the "high water mark".

m_up_limit_id：

The read should see all trx ids which are strictly smaller (<) than this value.

In other words, this is the "low water mark".

m_creator_trx_id：trx id of creating transaction

m_ids：Set of read view transactions that was active when this snapshot was taken

The above fields , The usage is as follows

 

When a transaction accesses a record , Except that your own update records are always visible , There are also these situations ：

• If it's recorded trx_id Less than Read View Medium m_up_limit_id value , Indicates that the record of this version is created Read View front Generated by a committed transaction , Therefore, the record of this version is valid for the current transaction so .

• If it's recorded trx_id A value greater than or equal to Read View Medium m_low_limit_id value , Indicates that the record of this version is created Read View after Generated by a transaction that was started , Therefore, the record of this version is valid for the current transaction invisible .

• If it's recorded trx_id Values in Read View Of m_up_limit_id and m_low_limit_id Between , You need to determine trx_id Whether in m_ids In the list ：
  • If it's recorded trx_id stay m_ids In the list , Indicates that the active transaction generating the version record is still active （ The transaction hasn't been committed yet ）, Therefore, the record of this version is valid for the current transaction invisible .

• If it's recorded trx_id be not in m_ids In the list , Indicates that the active transaction generating the version record has been committed , Therefore, the record of this version is valid for the current transaction so .

Create different isolation levels Read View What is the timing of ？

Repeatable

When the isolation level is repeatable , Is to create a when the transaction starts Read View, Use this throughout the transaction Read View

here , The database data is like this

 

Let's recreate , How to solve the problem of repeatable reading in the same transaction , It can keep consistent data after reading twice .

Business A It's a read operation , It says , Repeatable read is to create a when the transaction starts Read View, When a transaction A perform ：select * from score; when , All data in the database will be related to transactions A Created Read View The comparison , Find out 1-5 The business of id All at low water level m_up_limit_id following , So the data found is full data .

 

Business B To modify the operation , Raise Qian Xiaoliu's score 10 branch . At this time, the data in the database looks like this ：

 

At this point, the transaction A When executing the query again , Found Qian Xiaoliu DB_TRX_ID Than what I created Read View The business of id Big , So according to the rollback pointer , find undo log Historical record , Read Qian Xiaoliu DB_TRX_ID=5 This log data

Read submitted

The isolation level is when the read has been committed , Is in sql Create a Read View

This analysis method is the same as that of repeatable reading , Suppose you are now under the isolation level of repeatable reading ,

Step one ：A The transaction reads data once , Transaction not committed

 

Step two ：B The score of Qian Xiaoliu was revised to 90 branch

 

Step three ：A The transaction reads the table data again

Before reading , The database looks like this ：

 

There are two scenarios ：

1、 Suppose step 2 B Transaction not committed

 

because 7 Still active , So for the current version, for transactions A invisible .

2、 Suppose step 2 B The transaction is committed

 

The current version of Qian Xiaoliu's affairs id Number is 7, Just in the middle of high water level and low water level , This situation , We need to see 7 Is it active or not , obviously m_ids It doesn't contain 7, So the current version is for transactions A so .

Conclusion ：

1、Read View Help with business , Depending on the isolation level , Determine whether the current version is visible to transactions . Different isolation levels create Read View The timing is different , Can cause Read View Key fields record transactions id Somewhat different , This is why different isolation levels access the same database data , But the underlying reasons for reading different data .

2、MVCC Namely ： The implementation of different isolation levels is Through affairs Read View Fields in and Two hidden column fields in each row of records Comparison of , To control the technology when concurrent transactions access the same record