Three kinds of bugs:
Dirty read:
Example:, insert into T values (4, '牛D');then no commit. The data read by
other processes SELECTis uncommitted data. (The database only modified the memory but not the external memory)
Non-repeatable reading:
Example: Two identical queries within the scope of a transaction return different data (because a process in the middle has modified the value and submitted successfully)
Phantom reading:
Example: A certain transaction is reading a certain range of data, but another transaction inserts data into this range of data, which causes the number of rows of data to be inconsistent when it is read multiple times.
1. READ UNCIMMITTED (uncommitted read)
in this isolation level, the query will not be locked, and because the query is not locked, the consistency of this isolation level is the worst, which may produce "dirty" "Reading", "non-repeatable reading", "phantom reading".
2. READ COMMITTED
means that you can only read the content that has been submitted.
Why is there no query lock for submitted reads and uncommitted reads, but dirty reads can be avoided ?
This is about another mechanism-snapshot (snapshot)
When B inserts a piece of data and then commits, at this time A executes select, then there will be the piece of data added by B in the returned data... It does not matter whether there are other transactions committing afterwards, because the photo has been generated , And it won’t regenerate. I will refer to this photo in the future.
-
Assuming there is no "snapshot read", when an updated transaction is not committed, another transaction that queries the updated data will be blocked because it cannot be queried. In this case, the concurrency capability is quite poor.
-
The "snapshot read" can complete highly concurrent queries, but "read commit" can only be avoided
脏读, and cannot avoid "non-repeatable read" (insert INSERT is not update UPDATE) and "phantom read".
3. REPEATABLE READ (repeatable read)
ordinary queries also use "snapshot read", but, unlike "read commit", when the transaction is started, the "modification operation (Update)" is not allowed. The "non-repeatable read" is precisely because the data is modified between the two reads. Therefore, the "repeatable read" can be effectively avoided不可重复读 , but the "phantom read" cannot be avoided , because the phantom read is due to "insertion or Delete operation (INSERT or DELETE)” instead of update (UPDATE).
4. At the
level of SERIALIZABLE (serializable) , transactions are "serialized and executed sequentially", that is, they are executed one by one in a queue . Because he adds a large number of locks, resulting in a large number of request timeouts, the performance will be relatively low, and it is possible to consider this isolation level when data consistency is particularly needed and the amount of concurrency does not need to be that large.