Learn about MySQL transaction isolation level

Catalog

Preface

1. Four transaction isolation levels

1.1 READ UNCOMMITTED

1.2 READ COMMITTED

1.3 REPEATABLE READ

1.4 SERIALIZABLE

1.5 Summary

2. Problems in concurrent transactions

2.1 Dirty reading

2.2 It can't be read repeatedly

2.3 Fantasy reading

3. Isolation level actual combat

3.1 Query transaction isolation level

3.2 Set the transaction isolation level

3.3 Dirty reading problem

3.4 Unrepeatable read problem

3.5 The problem of unreal reading

summary

Preface

MySQL The transaction isolation level is used to solve the problem that concurrent transactions interfere with each other ,MySQL The total transaction isolation levels are as follows 4 Kind of ：

READ UNCOMMITTED： Read uncommitted .

READ COMMITTED： Read submitted .

REPEATABLE READ： Repeatable .

SERIALIZABLE： serialize .

1. Four transaction isolation levels 1.1 READ UNCOMMITTED

Read uncommitted , Also known as uncommitted reads , Transactions at this isolation level can see uncommitted data in other transactions . This isolation level is because uncommitted data in other transactions can be read , Uncommitted data may be rolled back , Therefore, we call the data read at this level dirty data , Call this problem dirty reading .

1.2 READ COMMITTED

Read submitted , Also called submit read , Transactions at this isolation level can read the data of committed transactions , So it won't have dirty reading problems . However, the results submitted by other transactions can be read during the execution of transactions , So the same at different times SQL Querying , It's possible to get different results , This phenomenon is called unrepeatable reading .

1.3 REPEATABLE READ

Repeatable ,MySQL Default transaction isolation level . Repeatable reading can solve “ It can't be read repeatedly ” The problem of , But there is still the problem of unreal reading . The so-called unreal reading refers to , Use the same... At different times in the same transaction SQL When inquiring , It will produce different results . for example , One SELECT It was executed twice , But the second time it returns a line that was not returned the first time , So this line is a “ Visions ” That's ok .

Be careful ： The emphasis of unreal reading and unrepeatable reading is different , Non repeatable reading focuses on data modification , The same row of data read twice is different ; Unreal reading focuses on adding or deleting , The number of data rows returned by the two queries is different .

1.4 SERIALIZABLE

serialize , The highest level of transaction isolation , It forces the transaction to be sorted , So that there will be no conflict , Thus, the problem of dirty reading is solved 、 Non repetition and unreal reading , But because the execution efficiency is low , So there are not many real scenarios .

1.5 Summary

Just to summarize ,MySQL The transaction isolation level in is to solve dirty reads 、 Non repeatable reading and unreal reading , this 4 The isolation level is similar to this 3 The corresponding relationship between the questions is as follows ：

Transaction isolation level Dirty reading It can't be read repeatedly Fantasy reading

Read uncommitted （READ UNCOMMITTED）	√	√	√
Read submitted （READ COMMITTED）	×	√	√
Repeatable （REPEATABLE READ）	×	×	√
Serialization （SERIALIZABLE）	×	×	×

2. Problems in concurrent transactions

The following exist in concurrent transactions 3 A question .

2.1 Dirty reading

One transaction reads the data saved by another transaction for commit , Then the transaction is rolled back , This causes the first transaction to read a dirty data that does not exist .

2.2 It can't be read repeatedly

In the same transaction , The same query gets different results at different times . For example, the transaction is in T1 Read a row of data , stay T2 Time to reread this line , The data in this line has been modified , So when I read it again, I get an and T1 Different results when querying .

2.3 Fantasy reading

MySQL The definition of unreal reading is as follows ：

The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row.

Official documents ： Translated into Chinese is ： The same query gets different results at different times , This is the problem of unreal reading in transactions . for example , One SELECT It was executed twice , But the second time it returns a line that was not returned the first time , So this line is a “ Visions ” That's ok .

3. Isolation level actual combat 3.1 Query transaction isolation level

Look at the big picture MySQL Of the transaction isolation level and the transaction isolation level of the current session SQL as follows ：

select @@global.tx_isolation,@@tx_isolation;

above SQL The execution result is shown in the figure below ： 

3.2 Set the transaction isolation level

Each is connected to MySQL The client of can set the isolation level of transactions separately ,MySQL You can use the following SQL Set current connection （ client ） Transaction isolation level for ：

set session transaction isolation level Transaction isolation level ;

The transaction isolation levels are 4 It's worth ：

READ UNCOMMITTED

READ COMMITTED

REPEATABLE READ

SERIALIZABLE

3.3 Dirty reading problem

One transaction reads the data saved by another transaction for commit , Then the transaction is rolled back , This causes the first transaction to read a dirty data that does not exist . Next , We use SQL To demonstrate the dirty reading problem .

Before the official start , First create a test table ：

-- Create a city table drop table if exists city;create table city( id int primary key auto_increment, name varchar(250) not null);

The dirty reads are executed in the following order ： 

  Dirty read execution SQL The sequence of and execution is as follows ：

client A：set session transaction isolation level read uncommitted;

client A：start transaction;

client B：start transaction;

client B：insert into city(name) values(' Xi'an ');

client A：select * from city;

client B：rollback;

client A：select * from city;

The corresponding execution results are shown in the following figure ： 

  As can be seen from the above results , When the client A Set to read uncommitted transaction isolation level , client A You can read uncommitted data from other transactions , When other transactions are rolled back , client A The read data becomes dirty data , This is dirty reading , That is to say There is a dirty read problem in the uncommitted transaction isolation level .

3.4 Unrepeatable read problem

In the same transaction , The same query gets different results at different times . For example, the transaction is in T1 Read a row of data , stay T2 Time to reread this line , The data in this line has been modified , So when I read it again, I get an and T1 Different results when querying .

The non repeatable reads are executed in the following order ： 

  Non repeatable read execution SQL The sequence of and execution is as follows ：

client A：set session transaction isolation level read committed;

client A：start transaction;

client A：select * from city where id=1;

client B：start transaction;

client B：update city set name=' changan ' where id=1;

client B：commit;

client A：select * from city where id=1;

The corresponding execution results are shown in the following figure ： 

  As can be seen from the above results , client A After the read committed transaction isolation level is set , Use the same SQL The same piece of data read twice , The content is different , This is unrepeatable reading . That is to say Read the committed transaction isolation level , There may be a problem of non repetition .

3.5 The problem of unreal reading

The same query gets different results at different times , This is the problem of unreal reading in transactions . for example , One SELECT It was executed twice , But the second time it returns a line that was not returned the first time , So this line is a “ Visions ” That's ok .

The execution sequence of unreal reading is as follows ： 

  The execution of unreal reading SQL The sequence of and execution is as follows ： client A：set session transaction isolation level repeatable read; client A：start transaction; client A：select * from city where id<5; -- Query out 1 Data client B：start transaction; client B：insert into city(id,name) values(2,' Beijing '); client B：commit; client A：update city set name=' Beijing ' where id=2; client A：select * from city where id<5; -- Query out 2 Data The corresponding execution results are shown in the following figure ： 

  As can be seen from the above results , client A After the transaction isolation level that can be read repeatedly is set , Use the same SQL But the result is the same , A piece of data was found for the first time , The second time, two pieces of data were found , The extra row of data is called “ Visions ” That's ok , So we can get the result , There may be the problem of unreal reading in repeatable reading .

summary

MySQL There is 4 Transaction isolation level ： Read uncommitted （ There is dirty reading / It can't be read repeatedly / The problem of unreal reading ）、 Read submitted （ There is no repeatable reading / The problem of unreal reading ）、 Repeatable （ There is the problem of unreal reading ） And serialization , Which can be read repeatedly is MySQL Default transaction isolation level . Dirty read refers to reading uncommitted data of other transactions , Unrepeatable reading refers to reading data modified by other transactions , Phantom reading is to read the new or deleted data of other transactions “ Visions ” Row data .

This article is about one article MySQL This is the end of the article on transaction isolation level , More about MySQL For the content of transaction isolation level, please search the previous articles of SDN or continue to browse the relevant articles below. I hope you will support SDN more in the future ！