MySQL transaction isolation level
- Read uncommitted
data changed in one transaction, although it has not yet been committed, the changed data can be seen in another transaction - Read committed
When a transaction is committed, the data changed in the transaction can be seen in other transactions - Repeatable reading In the
same transaction, the same query condition is queried multiple times, and the data is consistent - Serialization
Locks the rows accessed in a transaction (read-write lock), other transactions have lock conflicts, and block waiting for the execution of the previous transaction to complete and commit, and then continue execution
mysql innodb engine default transaction isolation level
Repeatable
Problems with different isolation levels
- Dirty read When the
read is not committed, the updated data in transaction B is read during the execution of transaction A, and then transaction B is rolled back.
Not the point, don't say too much. Basically, this isolation level is not used, and the least read has been submitted. - Non-repeatable reading In
a transaction, the same query condition statement is executed two or more times before and after the query, and the query result data is inconsistent.
For example: select name from user where id = 1; The
result of the first query in a transaction is Zhang San, and the result of another query is Li Si. - Phantom reads
In a transaction, 2 or more queries (range queries), the number of result rows is inconsistent.
Such as: select * from user where name='Zhang San'; 2 rows for the first time, and 3 rows again.
Or: select * from user where age >20 and age <30, the first query returns 100 rows, the second time 101 rows, etc.
Non-repeatable reading and phantom reading boundary
Non-repeatable reading occurs because: when a transaction is executed multiple queries, the query result is modified by another transaction (another transaction is submitted, and the current transaction needs to be queried again), and the results are inconsistent .
The phantom read is because of the range query result of transaction A. Other transactions have added corresponding rows in this range. After submission, transaction A sees that the number of rows is inconsistent .
Therefore, note that under the repeatable read isolation level: phantom reads only refer to newly inserted rows . Second, it needs to be seen by other transactions. The general query at this level is snapshot read. If it is to be seen, it needs to be current read (for update is added after the query, and all the latest changes can be seen). Avoid phantom reads and need to add gaps Lock, lock the relevant range interval, and other transactions cannot add new records (repeatable read level, gap lock takes effect).
The results are also inconsistent, and the difference is here.
ps Actually, until I work now, I have never encountered a phantom reading in actual business, and I still have to understand the concept.