MySQL transaction isolation level

Transaction isolation level	Dirty reading	It can't be read repeatedly	Fantasy reading
Read uncommitted （read-uncommitted）	yes	yes	yes
It can't be read repeatedly （read-committed）	no	yes	yes
Repeatable （repeatable-read）	no	no	yes
Serialization （serializable）	no	no	no

　　1、 Read uncommitted ：

　　　　（1） Open a client A, And set the current transaction mode to read uncommitted（ Uncommitted read ）, Query table account The initial value of the ：

 

　　　　（2） On the client side A Before the transaction is committed , Open another client B, Update table account：

 

　　　　（3） At this time , Although the client B The business of has not been submitted , But the client A You can find B Updated data ：

 

　　　　（4） Once the client B The transaction of is rolled back for some reason , All operations will be undone , That client A The data queried is actually dirty data ：

 

 　　　　（5） On the client side A Execute UPDATE statement update account set balance = balance - 50 where id =1,lilei Of balance Did not become 350, was 400, Isn't that weird? , The data are inconsistent , It would be naive of you to think so 了 , In the application , We will use 400-50=350, I didn't know that other sessions rolled back , To solve this problem, read committed isolation level

　　2、 Read submitted

　　　　（1） Open a client A, And set the current transaction mode to read committed（ Uncommitted read ）, Query table account All records ：

 

　　　　（2） On the client side A Before the transaction is committed , Open another client B, Update table account：

 

　　　　（3） At this time , client B The business of has not been submitted , client A Can't find B Updated data , Solved the problem of dirty reading ：

 

　　　　（4） client B Transaction commit for

　　　　（5） client A Execute the same query as in the previous step , result Inconsistent with the previous step , That is to say, there is the problem of non repetition

 　　3、 Repeatable

 　　　　（1） Open a client A, And set the current transaction mode to repeatable read, Query table account All records

　　　　（2） On the client side A Before the transaction is committed , Open another client B, Update table account And submit

　　　　（3） On the client side A Query table account All records , And steps （1） The results are consistent , There is no non repeatable reading problem

　　　　（4） On the client side A, Then perform update balance = balance - 50 where id = 1,balance Did not become 400-50=350,lilei Of balance It's worth the steps （2） Medium 350 To calculate , So it is 300, The consistency of the data has not been broken . Used under the isolation level of repeatable reading MVCC Mechanism ,select Operation will not update version number , It's snapshot reading （ Version history ）;insert、update and delete Will update version number , It's the current reading （ current version ）.

（5） Reopen the client B, Insert a new data and submit

（6） On the client side A Query table account All records , No, Find out The new data , So there is no unreal reading

　　4. Serialization

　　　　（1） Open a client A, And set the current transaction mode to serializable, Query table account The initial value of the ：

mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from account;
+------+--------+---------+
| id   | name   | balance |
+------+--------+---------+
|    1 | lilei  |   10000 |
|    2 | hanmei |   10000 |
|    3 | lucy   |   10000 |
|    4 | lily   |   10000 |
+------+--------+---------+
4 rows in set (0.00 sec)

　　　　（2） Open a client B, And set the current transaction mode to serializable, Insert a record to report an error , Table locked insert failed ,mysql The transaction isolation level in is serializable It locks the watch , So there will be no unreal reading , This isolation level is extremely low in concurrency , It's rarely used in development .

mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into account values(5,'tom',0);
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction