Isolation level of MySQL database transactions (detailed explanation)

One 、 summary

There are four levels of isolation for database transactions ：（ The following is the problem to be solved , In combination with the following cases ）

1. Read uncommitted （Read Uncommited） Business 1 The modified data is transacted 2 Rolled back

2. Read submitted （Read Commited） Business 1 Read the information that other transactions have been modified but not submitted

3. Repeatable degrees （Repeatable Read） In the transaction 1 When performing multiple query operations , The results of the query are inconsistent

4. Serializable （Serializable） When querying in the same transaction, many more records are found

Two 、 The reason why the isolation level appears

In order to solve the problem in Concurrent execution It doesn't affect each other , Therefore, the isolation level of transactions is introduced （ That is, reading one data at the same time in multiple transactions 、 When updating and other operations , How to ensure the correctness and consistency of data ）

3、 ... and 、 The problems solved by the four transaction isolation levels

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

Four 、 Problems solved by different isolation levels

• Dirty write （ Business 1 The modified data is transacted 2 Rolled back ）

	Business 1	Business 2
T1	begin
T2		begin
T3		update xxx set password= 200 where id = 1
T4	update xxx set password= 1000 where id = 1
T5	commit
T6		Rollback

         Here you can see the transaction 1 After the revision id by 1 Of password And commit the transaction , Business 2 stay T6 The transaction is rolled back at any time , And that leads to this Business 1 The modification of data is lost 了 , This is a very serious mistake , That is, the data you modified was rolled back , Dirty writes are solved at any isolation level .

• Dirty reading （ Business 1 Read the information that other transactions have been modified but not submitted 、 Temporary information ）

	Business 1	Business 2
T1	begin
T2		begin
T3		update xxx set password= 99 where id = 1
T4	select password from xxx where id = 1
T5	commit
T6		RollBack

        Business here 1 stay T4 Transaction read 2 in the light of id=1 Of users password modify , But actually things 2 At last, the transaction is rolled back , This leads to actual transactions 1 What I read is a nonexistent data , That's business 1 Read other transaction modifications but did not mention the submitted record information . The dirty read problem is solved under the isolation level of read committed .

• Non repeatability （ When the same transaction performs multiple query operations , The results of the query are inconsistent ）

	Business 1	Business 2
T1	begin
T2		begin
T3	select password from xxx where id = 1
T4		update xxx set password = 99 where id = 1
T5	select password from xxx where id = 1
T6		update xxx set password= 88 where id = 1
T7	select password from xxx where id = 1
T8		update xxx set password= 88 where id = 1
T9	commit
T10		commit

        stay T3、T5、T7 Time affairs 1 Yes id=1 The account number of password, It is found that the data is consistent and changing , This is the problem of non repeatability , In the same business Data changes every time you query , Under the isolation level of repeatability, the non repeatable problem is solved .

• Fantasy reading （ When querying in the same transaction, many more records are found , It is called phantom recording ） 

	Business 1	Business 2
T1	begin
T2		begin
T3	select * from xxx where id > 100
T4		insert into xxx(id,password) values (199,11)
T5	select * from xxx where id > 100
T6		insert into xxx(id,password) values (200,11)
T7	select * from xxx where id > 100
T8		insert into xxx(id,password) values (201,11)
T9	commit
T10		commit

        stay T3、T5、T7 Time affairs 1 Yes id Greater than 100 When querying the information of , It is found that new data will appear every time you query in the same transaction , This is the unreal reading problem , In serializable （ serialize ） The problem of unreal reading is solved under the isolation level of

  5、 ... and 、 Confusion point & Knowledge point

• When you query many times, you find that there is less data , Is it unreal reading or unrepeatable

answer ： Non repeatability . Unreal reading must be the increase of data （ It can be understood literally , Phantom reading is the phantom record , Then there is more data found after reading twice ）, If the data is reduced , Then it is non repeatability

•   Rollback of dirty write and dirty read

Both are due to transactions 1 Problems caused by rollback of other transactions during operation , Dirty write refers to the invalidation of the data written by oneself due to the rollback of other transactions , Dirty read means that invalid data is read due to rollback of other transactions , Because dirty writes are resolved at all transaction isolation levels , So just understand （ Generally, it can be solved by locking ）

• The problem severity of the four isolation levels

Problem severity ： Dirty write > Dirty reading > It can't be read repeatedly > Fantasy reading

• stay MYSQL Transaction isolation level in

stay MySQL in innodb The isolation level under the storage engine is repeatable , But thanks to innodb Of MVCC version control ,MYSQL At the same time, the problem of unreal reading is solved under the isolation level of repeatability

6、 ... and 、 Comparison and summary of four isolation levels

• concurrency

You can understand it literally ：

1. Serializable Concurrency is the lowest , All transactions are waiting to be executed , Solve all the problems , High safety , But it's inefficient

2. After that, the concurrency ability increases by one ： Serialization < Repeatable degrees < Read submitted < Read uncommitted

3. In the actual development, according to the specific needs of the business , Weigh concurrency and data security and choose the corresponding isolation level