Isolation transactions is complicated by the need to understand clearly operating problems .MySQL There are four different levels of isolation, the four isolation levels are:
| Type isolation level | affect the result |
| READ UNCOMMITTED (uncommitted read) | Services will read uncommitted data may cause dirty reads, repeatable read and phantom read phenomenon, is a lower isolation level, less use in practice |
| READ COMMITTED (read committed) | The species when the transaction isolation level 1 is not committed or rolled back, the transaction 2 can avoid dirty reads, but after a commit or roll back the transaction, the transaction 2 appeared in the case repeatable read and phantom read |
| REPEATABLE READ (repeatable read) | Repeatable Read isolation level is the default MySQL can effectively avoid dirty reads and re-read the situation, but can not prevent phantom read |
| SERIABLIZABLE (serialization) | Can simultaneously solve dirty reads, repeatable read and phantom read the situation, but because the situation will be blocked, so the actual use is also less |
As can be seen, different isolation levels have different execution result of multiple transactions. The default isolation level in MySQL InnoDB storage engine is repeatable read (REPEATABLE READ).
As used herein, we demonstrate four isolation levels (based MySQL5.7) listed in the table. TABLE used is test, test the fields are id, name.
mysql> select * from test; +------+-------+ | id | name | +------+-------+ | 100 | zhangsan | | 200 | lisi | +------+-------+
Because MySQL is enabled by default implicit transaction, so in order to effect the operation will not be affected, the transaction needs to be turned into an explicit, while two started the session window and start a session of two windows need such operations. in the first window to perform:
mysql> set autocommit=0;
1、READ UNCOMMITTED
Query results can be seen from the following, MySQL in the default isolation level is REPEATABLE READ:
mysql> SELECT @@tx_isolation; +-----------------+ | @@tx_isolation | +-----------------+ | REPEATABLE-READ | +-----------------+
Therefore it needs to be the default isolation level to READ UNCOMMITED:
mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; Query OK, 0 rows affected (0.00 sec)
(1) In the first window to execute:
mysql> UPDATE test SET name='wangwu' WHERE id=100; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0
(2) in the second query table test window:
mysql> SELECT * FROM test; +------+--------+ | id | name | +------+--------+ | 100 | wangwu | | 200 | lisi | +------+--------+ 2 rows in set (0.00 sec)
As can be seen from the above output, id = 100 corresponding to the name is wangwu.
(3) is then performed on the first window ROLLBACK operation again in the second query window, id = 100 corresponding to the name of zhangsan, illustrate the READ UNCOMMITTED inevitable dirty read isolation levels. There is no re-read and test the case of the phantom read, because if not avoid dirty read, then the situation will be repeatable read and phantom read occurs.
mysql> select * from test; +------+----------+ | id | name | +------+----------+ | 100 | zhangsan | | 200 | lisi | +------+----------+ 2 rows in set (0.00 sec)
2、READ COMMITTED
The first and second window isolation levels are set to:
mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; Query OK, 0 rows affected (0.00 sec)
Re-open a transaction in the first window:
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec)
The first window is then performed (at this time no commit or rollback operation):
mysql> update test set name='wangwu' where id=100; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0
In the second window in the query test:
mysql> select * from test; +------+----------+ | id | name | +------+----------+ | 100 | zhangsan | | 200 | lisi | +------+----------+ 2 rows in set (0.00 sec)
After we found by the above output, using READ COMMITTED isolation level, where there is no dirty read occurs. But when a commit in a window, the results obtained from the query window II has changed:
mysql> select * from test; +------+--------+ | id | name | +------+--------+ | 100 | wangwu | | 200 | lisi | +------+--------+ 2 rows in set (0.00 sec)
Thus it is seen that in both cases before and after and commit obtained are not identical, thus not explained to avoid READ COMMITTED repeatable read.
3、REPEATABLE READ
Before the start of the data:
mysql> select * from test; +------+----------+ | id | name | +------+----------+ | 100 | zhangsan | | 200 | lisi | +------+----------+ 2 rows in set (0.00 sec)
Similarly, the first and second window isolation levels are set to:
mysql> SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; Query OK, 0 rows affected (0.00 sec)
The first window of execution:
mysql> SET AUTOCOMMIT=0; Query OK, 0 rows affected (0.00 sec)
In the first test of a window update name:
mysql> UPDATE test set name='xiaoming' where id=100; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0
In the second window query test:
mysql> select * from test; +------+----------+ | id | name | +------+----------+ | 100 | zhangsan | | 200 | lisi | +------+----------+ 2 rows in set (0.00 sec)
At this discovery, data query in a second window has not changed, REPEATABLE READ avoid dirty reads.
Meanwhile, when the first submission window update query is executed, the data does not change in the second window, also to avoid the case described where a repeatable read.
mysql> select * from test; +------+----------+ | id | name | +------+----------+ | 100 | zhangsan | | 200 | lisi | +------+----------+ 2 rows in set (0.00 sec)
In the second window, no matter how many times read, read data will not be updated in the first window data only when the second window also submit, at this time of the second window will be updated data.
mysql> select * from test; +------+----------+ | id | name | +------+----------+ | 100 | xiaoming | | 200 | lisi | +------+----------+ 2 rows in set (0.00 sec)
Finally, the data is inserted in a second window:
mysql> insert into test values(300,'wangwu'); Query OK, 1 row affected (0.00 sec)
In the first window update data Logically, there should be two rows of data affected, but this time found to have three lines of data affected, indicating the emergence of the phenomenon of phantom read:
mysql> update test set name='zhaoliu'; Query OK, 3 rows affected (6.36 sec) Rows matched: 3 Changed: 3 Warnings: 0
4、 SERIALIZABLE
The first and second window isolation levels are set to:
mysql> SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE; Query OK, 0 rows affected (0.00 sec)
Before the start of operations data:
+------+---------+ | id | name | +------+---------+ | 100 | zhaoliu | | 200 | zhaoliu | | 300 | zhaoliu | +------+---------+ 3 rows in set (0.00 sec)
When the insert operation in window 2, blocking phenomenon occurs, because the window did not submit 1 (ie, not release the lock), and only when the window 1 to perform the commit operation, data is inserted in the window 2 more success.
In this paper, verification of MySQL in four isolation levels by way of experiment. Can effectively deepen understanding of these four isolation levels.
If wrong, please correct me. Thank you