Mysql33 multi version concurrency control

One . What is? MVCC

MVCC （Multiversion Concurrency Control）, Multi version concurrency control . seeing the name of a thing one thinks of its function ,MVCC Multiple versions of the database are used to manage the data concurrency control . This technology makes it possible to InnoDB Execute at the transaction isolation level of Read consistency The operation is guaranteed . In other words , To query some rows that are being updated by another transaction , And you can see their values before they are updated , In this way, when doing the query, you don't have to wait for another transaction to release the lock .

Two . Snapshot read and current read

MVCC stay MySQL InnoDB In order to improve the database concurrency performance , Deal with it in a better way read - Write conflict , Even if there is a conflict between reading and writing , Can also do No locks , Non blocking concurrent read , And this reading refers to Read the snapshot , Instead of The current reading . The current reading is actually a lock operation , It's the realization of pessimistic lock . and MVCC The essence is a way of adopting optimistic lock thought .

2.1. Read the snapshot

Snapshot reading is also called consistent reading , Read snapshot data . Simple without lock SELECT All belong to snapshot reading , Non blocking read without lock ; Such as this ：

SELECT * FROM player WHERE ...

The reason why snapshot reading occurs , It is based on the consideration of improving concurrent performance , The implementation of snapshot reading is based on MVCC, In many cases , Avoid lock operation , Lower the cost .
Since it's based on multiple versions , What the snapshot may read is not necessarily the latest version of the data , It could be the previous version of history .
The premise of snapshot read is that isolation level is not serial level , Snapshot reads at the serial level degrade to current reads .

2.2. The current reading

The latest version of the record is currently being read （ The latest data , Instead of historical versions of the data ）, When reading, it is also necessary to ensure that other concurrent transactions cannot modify the current record , Will lock the read record . The lock SELECT, Or add, delete and modify the data, which will be read currently . such as ：

SELECT * FROM student LOCK IN SHARE MODE; #  Shared lock 
SELECT * FROM student FOR UPDATE; #  Exclusive lock 
INSERT INTO student values ... #  Exclusive lock 
DELETE FROM student WHERE ... #  Exclusive lock 
UPDATE student SET ... #  Exclusive lock 

3、 ... and . review

3.1. Let's talk about the isolation level again

We know that business has 4 Isolation levels , There are three possible concurrency problems ：

Another picture ：

3.2. Hide fields 、Undo Log Version chain

Take a look back. undo The version chain of the log , For the use of InnoDB For the table of the storage engine , Its clustered index records contain two necessary hidden columns .

• trx_id ： Every time a transaction changes a clustered index record , Will take the matter Business id Assign a value to trx_id Hide columns .
• roll_pointer ： Every time a cluster index record is changed , Will write the old version to undo journal in , Then the hidden column is equivalent to a pointer , It can be used to find the information before the modification of the record .
  
  insert undo Works only when a transaction is rolled back , When the transaction is committed , This type of undo The journal is useless , It takes up Undo Log Segment It's also recycled by the system （ That is the undo The log occupies Undo Page linked lists are either reused , Or be released ）
  Suppose the next two transactions id Respectively 10 、 20 The transaction for this record UPDATE operation , The operation process is as follows ：

Time sequence of occurrence	Business 10	Business 20
1	BEGIN;
2		BEGIN;
3	UPDATE student SET name=“ Li Si ” WHERE id=1;
4	UPDATE student SET name=“ Wang Wu ” WHERE id=1
5	COMMIT;
6		UPDATE student SET name=“ Qian Qi ” WHERE id=1;
7		UPDATE student SET name=" Song Ba "WHERE id=1;
8		COMMIT;

Every time the record is changed , They all record one undo journal , Every one of them undo There's one in every log roll_pointer attribute （ INSERT The operation corresponds to undo Log does not have this property , Because there is no earlier version of this record ）, You can put these undo The logs are all connected , String into a linked list ：

After each update of the record , Will put the old value in one undo journal in , Even an old version of the record , As the number of updates increases , All versions will be roll_pointer Attributes are connected into a linked list , We call this list Version chain , The header node of the version chain is the latest value of the current record .
Each version is also included in the generated version Business id .

Four . MVCC The realization principle is ReadView

MVCC The realization of depends on ： Hide fields 、Undo Log、Read View.

4.1. Design thinking

Use READ UNCOMMITTED Isolation level transactions , Because you can read the modified records of uncommitted transactions , So just read the latest version of the record .
Use SERIALIZABLE Isolation level transactions ,InnoDB Specify the use of locks to access records .
Use READ COMMITTED and REPEATABLE READ Isolation level transactions , Must be sure to read Have submitted Transaction modified records . If another transaction has modified the record but has not yet committed , You can't read the latest version of the record directly , The core problem is to judge which version in the version chain is visible to the current transaction , This is a ReadView The main problem to be solved .
This ReadView It mainly includes 4 A more important content , They are as follows ：

• creator_trx_id , To create this Read View The business of ID.
  explain ： Only when you make changes to the records in the table （ perform INSERT、DELETE、UPDATE These sentences are ） To assign a transaction to a transaction id, Otherwise, the transaction in a read-only transaction id Values default to 0.
• trx_ids , It means generating ReadView The number of active read-write transactions in the current system Business id list .
• up_limit_id , The smallest transaction in an active transaction ID.
• low_limit_id , To generate ReadView Should be assigned to the next transaction in the system id value .low_limit_id Is the biggest transaction in the system id value , Here we should pay attention to the transactions in the system id, Need to be different from the active transaction ID.

 Be careful ：low_limit_id Not at all trx_ids Maximum of , Business id It's incremental . such as , Now there is id by 1,
2,3 These three things , after id by 3 The transaction of has been submitted . Then a new read transaction is generated ReadView when ,
trx_ids Include 1 and 2,up_limit_id The value is 1,low_limit_id The value is 4.

4.3. ReadView The rules of

With this ReadView, So when you access a record , Just follow the steps below to determine if a version of the record is visible .

• If the accessed version of trx_id Property value and ReadView Medium creator_trx_id Same value , It means that the current transaction is accessing its own modified records , So this version can be accessed by the current transaction .
• If the accessed version of trx_id Attribute value less than ReadView Medium up_limit_id value , Indicates that the transaction generating this version generates ReadView Submitted before , So this version can be accessed by the current transaction .
• If the accessed version of trx_id Property value is greater than or equal to ReadView Medium low_limit_id value , Indicates that the transaction generating this version generates ReadView It's only opened after , So this version cannot be accessed by the current transaction .
• If the accessed version of trx_id The attribute value is ReadView Of up_limit_id and low_limit_id Between , Then we need to judge trx_id Is the attribute value in trx_ids In the list .

 If in , Description creation ReadView The transaction that generated this version is still active , This version is not accessible .
 If not , Description creation ReadView The transaction that generated this version has been committed , This version can be accessed .

4.4. MVCC The overall operation process

After understanding these concepts , Let's take a look at when querying a record , How the system passes through MVCC Find it ：

• First get the version number of the transaction itself , That's business ID;
• obtain ReadView;
• The data from the query , Then with ReadView Compare the transaction version number in the ;
• If it doesn't meet ReadView The rules , You need from Undo Log Take a historical snapshot in ;
• Finally, the data that meets the rules is returned .
  At the isolation level, read committed （Read Committed） when , Every time in a transaction SELECT The query will be retrieved again Read View.
  As shown in the table ：

Business	explain
begin;
select * from student where id >2;	Get once Read View
…
select * from student where id >2;	Get once Read View
commit;

Be careful , At this time, the same query statement will be retrieved again Read View, At this moment if Read View Different , It may lead to non repeatable reading or unreal reading .
When the isolation level is repeatable , You can't avoid repetition , This is because a transaction is only the first time SELECT You'll get it once Read View, And all the rest SELECT Will reuse this Read View, As shown in the following table ：

5、 ... and . Illustrate with examples

5.1. READ COMMITTED Under isolation level

READ COMMITTED ： Generate a... Before each read ReadView.
Now there are two Business id Respectively 10 、 20 Your transaction is executing ：

# Transaction 10
set session transaction isolation level READ COMMITTED;
begin;
UPDATE student SET name=" Li Si " WHERE id=1;
UPDATE student SET name=" Wang Wu " WHERE id=1;

# Transaction 20
BEGIN;
UPDATE student SET name=" Zhang Fei " WHERE id=1;
UPDATE student SET name=" Liu bei " WHERE id=1;

At the moment , surface student in id by 1 The linked list of versions obtained from the records is as follows ：

Let's say there's a use now READ COMMITTED Isolation level transactions start executing ：

#  Use READ COMMITTED Isolation level transactions 
BEGIN;
# SELECT1：Transaction 10、20 Not submitted 
SELECT * FROM student WHERE id = 1; #  Get the column name The value of is ' Zhang San '

after , We put Business id by 10 I'd like to submit my business ：

# Transaction 10
BEGIN;
UPDATE student SET name=" Li Si " WHERE id=1;
UPDATE student SET name=" Wang Wu " WHERE id=1;
COMMIT;

And then to Business id by 20 Update the table in the transaction student in id by 1 The record of ：

# Transaction 20
BEGIN;
#  Updated the records of some other tables 
...
UPDATE student SET name=" Qian Qi " WHERE id=1;
UPDATE student SET name=" Song Ba " WHERE id=1;

At the moment , surface student in id by 1 The version chain of records is so long ：
And then use it just now READ COMMITTED Continue to look for this in isolation level transactions id by 1 The record of , as follows ：

#  Use READ COMMITTED Isolation level transactions 
BEGIN;
# SELECT1：Transaction 10、20 None of them submitted 
SELECT * FROM student WHERE id = 1; #  Get the column name The value of is ' Zhang San '
# SELECT2：Transaction 10 Submit ,Transaction 20 Not submitted 
SELECT * FROM student WHERE id = 1; #  Get the column name The value of is ' Wang Wu '

5.2. REPEATABLE READ Under isolation level

Use REPEATABLE READ For isolation level transactions , Only one... Is generated when the query statement is executed for the first time ReadView , After that, the query will not be generated repeatedly .
such as , There are two in the system Business id Respectively 10 、 20 Your transaction is executing ：

# Transaction 10
BEGIN;
UPDATE student SET name=" Li Si " WHERE id=1;
UPDATE student SET name=" Wang Wu " WHERE id=1;
# Transaction 20
BEGIN;
#  Updated the records of some other tables 
...

At the moment , surface student in id by 1 The linked list of versions obtained from the records is as follows ：

Let's say there's a use now REPEATABLE READ Isolation level transactions start executing ：

#  Use REPEATABLE READ Isolation level transactions 
BEGIN;
# SELECT1：Transaction 10、20 Not submitted 
SELECT * FROM student WHERE id = 1; #  Get the column name The value of is ' Zhang San '

after , We put Business id by 10 I'd like to submit my business , Just like this. ：

# Transaction 10
BEGIN;
UPDATE student SET name=" Li Si " WHERE id=1;
UPDATE student SET name=" Wang Wu " WHERE id=1;
COMMIT;

And then to Business id by 20 Update the table in the transaction student in id by 1 The record of ：

# Transaction 20
BEGIN;
#  Updated the records of some other tables 
...
UPDATE student SET name=" Qian Qi " WHERE id=1;
UPDATE student SET name=" Song Ba " WHERE id=1;

At the moment , surface student in id by 1 The version chain of records is as long as ：

And then use it just now REPEATABLE READ Continue to look for this in isolation level transactions id by 1 The record of , as follows ：

#  Use REPEATABLE READ Isolation level transactions 
BEGIN;
# SELECT1：Transaction 10、20 None of them submitted 
SELECT * FROM student WHERE id = 1; #  Get the column name The value of is ' Zhang San '
# SELECT2：Transaction 10 Submit ,Transaction 20 Not submitted 
SELECT * FROM student WHERE id = 1; #  Get the column name The value of is still ' Zhang San '

5.3. How to solve unreal reading

Next InnoDB How to solve unreal reading .
Let's say that now the table student There's only one piece of data , In the data content , Primary key id=1, Hidden trx_id=10, its undo log As shown in the figure below .

Suppose there is a transaction now A And transaction B Concurrent execution , Business A The business of id by 20 , Business B The business of id by 30 .
step 1： Business A Start querying data for the first time , Of the query SQL The statement is as follows .

select * from student where id >= 1;

Before starting the query ,MySQL Will be for business A Produce a ReadView, here ReadView Is as follows ： trx_ids=[20,30] , up_limit_id=20 , low_limit_id=31 , creator_trx_id=20 .
At this time, due to student There's only one piece of data , And consistent with where id>=1 Conditions , So it will find out . And then according to ReadView Mechanism , Find the data in this row trx_id=10, Less than transaction A Of ReadView in up_limit_id, This means that this data is a transaction A Before opening , Data already submitted by other transactions , So the business A It can be read .
Conclusion ： Business A Your first query , Can read a piece of data ,id=1.
step 2： Then business B(trx_id=30), To the table student Insert two new pieces of data , And commit the transaction .

insert into student(id,name) values(2,' Li Si ');
insert into student(id,name) values(3,' Wang Wu ');

At this point, the table student There are three pieces of data in , Corresponding undo As shown in the figure below ：

step 3： Then business A Open the second query , According to the rules of repeatable read isolation level , At this point, the transaction A It won't regenerate ReadView. At this point, the table student Medium 3 All data meet where id>=1 Conditions , So we'll find out first . And then according to ReadView Mechanism , Determine whether each piece of data can be transacted A notice .
1） First id=1 This data of , I've already said that , Can be used by transactions A notice .
2） And then there was id=2 The data of , its trx_id=30, At this point, the transaction A Find out , This value is in up_limit_id and low_limit_id Between , So we need to judge again 30 Is it in trx_ids In array . Due to transaction A Of trx_ids=[20,30], So in the array , This means id=2 This data is related to the transaction A Committed by other transactions started at the same time , So this data cannot make transactions A notice .
3） Empathy ,id=3 This data of ,trx_id Also for the 30, Therefore, it cannot be used by transactions A See .

Conclusion ： Final transaction A The second query , Only query id=1 This data of . This and business A The results of the first query are the same , Therefore, there is no illusory reading phenomenon , So in the MySQL At the repeatable read isolation level of , There is no magic reading problem .

6、 ... and . summary

Here is the introduction of MVCC stay READ COMMITTD 、 REPEATABLE READ These two isolation level transactions access the version chain of records when performing snapshot read operations . This makes different transactions read - Write 、 Write - read Operations are executed concurrently , So as to improve the system performance .
The core point is ReadView Principle , READ COMMITTD 、 REPEATABLE READ One big difference between these two isolation levels is generation ReadView The timing is different ：

• READ COMMITTD In every ordinary SELECT Before operation, a ReadView.
• REPEATABLE READ Only for the first time SELECT Generate a before operation ReadView, This is repeated in subsequent query operations ReadView Just fine .