Isolation Levels
Database transaction isolation level there are four kinds, from low to high, respectively Read uncommitted, Read committed, Repeatable read, Serializable. Moreover, there may be a dirty read in the concurrent operation of its services, the non-repeatable read, phantom read.
- Read uncommitted (read uncommitted): is a transaction can read data from another uncommitted transactions. As follows, A, B when the two transactions access the same data in the case of concurrent, B transaction A transaction reads data modified but not submitted.
| A transaction | B Services | |
| 1 | A transaction open | |
| 2 | B transaction open | |
| 3 | A transaction is a read data 1000, and the use of update, the data 2000 to | |
| 4 | B read data transaction 2000 | |
| 5 | A transaction commits |
- Read committed (read submission): is a transaction have to wait another transaction commits to read the data. This transaction isolation level still have problems, a lot of people have doubts, read the contents of the transaction B is not just for the transaction after it submitted A, A and B transactions are not wrong, this will have any problems! ? Do not worry take your time, let's first four kinds of complete isolation level analysis.
| A transaction | B Services | |
| 1 | A transaction open | |
| 2 | B transaction open | |
| 3 | A transaction is a read data 1000, and the use of update, the data 2000 to | |
| 4 | A transaction commits | |
| 5 | B transaction reads data for 2000 |
- Repeatable read (repeatable read): When data is read at the start (open transaction), no longer allowed to modify the operation, but this representation is not rigorous. B accurate to say that the transaction to modify the data does not affect the data read A transaction, uh uh uh, what the hell? ? ? ? I myself confused. So I checked the Internet about the detailed information, is to figure out the principle.
Online describes: InnoDB save two hidden columns after each line records were deleted to save the time and the time to create lines of this line. Stored here is not the actual values of the time, but the system version number, when the data is modified, the version number is incremented by 1. When reading the start of the transaction, the transaction will give a version number, the current system data transactions will read the version number <= current version number . At this point if other write transaction modifies this data, the version number of this data will be incremented by one, thus higher than the current version number read transaction, read transaction data automatically enrolled after less than updated.
Here the version number column property abstract version, facilitate understanding.
| id | data | version |
| 1 | 1000 | 01 |
Table 1
| id | data | version |
| 1 | 2000 | 02 |
Table 2
| A transaction | B Services | |
| 1 | A transaction open, read id is 1 and version number of the data 01 | |
| 2 | B transaction open, read id is 1 and version number of the data 01 | |
| 3 | A transaction update data of the data, data equal to 2000, the version number of this data becomes 2 | |
| 4 | A transaction commits | |
| 5 | B firms get the version number of the data is still 1, B transaction reads data again, the result is still 1000 |
- The Serializable (serialization): Serializable transaction isolation level is the highest, at this level, execution serialization order of the transaction, to avoid dirty reads, non-repeatable read and phantom read. But this is inefficient transaction isolation level, database comparison consumption performance, is not generally used. Here do not do too much introduction.
Dirty reads (transaction level to read uncommitted cause)
A and B to read a data transaction, transaction A piece of data has been modified, the transaction B reads the data just after the modification A, but A does not submit the transaction, but in the subsequent process a rollback or modification of this data again, but B does not know the transaction, then the transaction can be said B data read is dirty, B transaction was dirty read.
| A transaction | B Services | |
| 1 | A transaction open | |
| 2 | B transaction open | |
| 3 | A transaction is a read data 1000, and the update data 2000 | |
| 4 | B read data transaction 2000 | |
| 5 | A transaction rollback occurs, the data back into 1000 | |
| 6 | Performing transaction operations update B, on the basis of the added 1000 2000 | |
| 7 | The transaction is committed, the result is 3000 (dirty). Actual data should be 2000 |
Non-repeatable read (read data level is set to commit or due to a lower level)
A and B a data read transaction, transaction A piece of data has been modified and submitted after the read data B, B when a transaction reads this data again, the data found changed. Here answered the questions mentioned above, the data level is set to READ COMMITTED isolation have not re-read errors may occur during concurrent.
| A transaction | B Services | |
| 1 | B transaction open | |
| 2 | A transaction open | |
| 3 | B is a read data transaction 1000 | |
| 4 | A transaction execution the update, data becomes 2000 | |
| 5 | A transaction has been submitted | |
| B transaction reads data again, the data of 2000 | ||
| Note | B before and after the transaction reads the same data twice, but the result is different, which is non-repeatable read |
Magic Reading (total amount of data read twice before inconsistent )
| A transaction | B Services | |
| 1 | A transaction open | |
| 2 | The number of data pieces is read 100 | |
| 3 | B transaction open | |
| 4 | New data can be added to the 50 | |
| 5 | Commit the transaction | |
| 6 | A number of data transactions to read again and found to be 150 | |
| Note | A前后两次读取的数据条数不相同，此为幻读 |
不可重复读和幻读的区别
不可重复度是针对update操作，幻读是针对insert操作delete操作
事务隔离级别与脏读、幻读和不可重读的关系（√：会出现 ×：不会出现）
| 脏读 | 不可重复读 | 幻读 | |
| 读未提交 | √ | √ | √ |
| 读提交 | × | √ | √ |
| 可重复度 | × | × | √ |
| 序列化 | × | × | × |