Before explaining dirty reads, non-repeatable reads, and phantom reads, let's talk about the transaction isolation level of the database. MySQL's transaction isolation level (Isolation Level) refers to: when multiple threads operate the database, the database is responsible for the isolation operation to ensure the accuracy of each thread in obtaining data. It is divided into four different levels, sorted by isolation level, read uncommitted<read submitted<repeatability<serialization.
What are dirty reads, non-repeatable reads, and phantom reads and how to solve them
Read uncommitted: The isolation level is the lowest and the isolation is the weakest. Dirty reads, non-repeatable reads, and phantom reads can all occur. So it basically exists in theory, no one uses it in actual projects, but it has the highest performance.
Read committed (Read committed): It ensures that no intermediate state data appears in the transaction, and all data is committed and updated, which solves the problem of dirty reads. However, the read committed level is still very low. It allows transactions to modify data concurrently, so there is no guarantee that the same data will be obtained when read again, that is, there is still the possibility of non-repeatable reads and phantom reads.
Repeatable reads: The default isolation level of the MySQL InnoDB engine ensures the consistency of data read multiple times in the same transaction and solves dirty reads and non-repeatable reads, but there is still the possibility of phantom reads.
Serializable: Selecting "Serializable" means that when reading data, you need to acquire a shared read lock; when you update data, you need to acquire an exclusive write lock; if SQL uses the WHERE statement, an interval lock is also acquired. In other words, when transaction A operates the database, transaction B can only wait in line, so the performance is the lowest.
The above is the transaction isolation level of the database. What are dirty reads, non-repeatable reads, and phantom reads are described below.
1. Dirty read: The data of the uncommitted transaction has been read.
Suppose there are two transactions A and B. In the case of concurrency, transaction A first starts to read the data in the commodity data table, and then performs the update operation. If transaction A has not submitted the update operation at this time, but transaction B happens to start, Then you also need to read the product data. At this time, transaction B queries the updated data of transaction A just now.
If transaction A triggers a rollback next, then the data just read by transaction B is stale data, and this phenomenon is dirty read.
How to solve "dirty read":
The isolation level of dirty reads is "read uncommitted", and only this isolation level will dirty reads occur.
The solution to dirty reads is to upgrade the transaction isolation level, such as "read committed".
2. Non-repeatable read: Transaction A reads a piece of data first, and then in the process of executing logic, transaction B updates this piece of data. When transaction A reads again, it finds that the data does not match. This phenomenon is "non-repeatable read".
How to solve "non-repeatable reading":
Simply put, the data read twice is modified in the middle, and the corresponding isolation level is "read uncommitted" or "read submitted".
The solution to non-repeatable reading is to upgrade the transaction isolation level, such as "repeatability".
3. Phantom reading: In a transaction, the same query statement is executed in different time periods, and different result sets are obtained.
Transaction A reads the commodity table once, and the final ID is 3, and transaction B also reads it once, and the final ID is also 3. Next, transaction A inserted a row, and then read that the latest ID was 4, which happened to be ID 3 plus 1, and then transaction B also inserted a row, and then read the latest ID and found that it was 5 instead of 3. plus 1.
When using ID to make judgments or do key data, there will be problems. This phenomenon is like making transaction B an illusion. An unexpected data is read, so it is called phantom reading. Of course, not only adding new data, but also deleting and modifying data, similar situations can happen.
How to solve "phantom reading":
Solve the problem that phantom reading cannot upgrade the transaction isolation level to "serializable", so the database also loses its concurrent processing capability.
Row locks cannot solve phantom reads, because even if all records are locked, it still cannot prevent the insertion of new data.
The solution to phantom reads is to lock the "gap" between records, so MySQL InnoDB introduces a new lock called gap lock (Gap Lock), which requires the use of gap locks to solve phantom reads.