One, the database transaction isolation level
There are four isolation levels for database transactions, from low to high, they are Read uncommitted, Read committed, Repeatable read, and Serializable. These four levels can solve the problems of dirty read, non-repeatable read, and phantom read one by one.
√: may appear ×: not appear
| Dirty read | Non-repeatable | Phantom reading | |
| Read uncommitted | √ | √ | √ |
| Read committed | × | √ | √ |
| Repeatable read | × | × | √ |
| Serializable | × | × | × |
Note: We discuss the isolation level scenario, mainly in the case of multiple concurrent transactions. Therefore, the following explanations will focus on transaction concurrency.
Read uncommitted
The company paid the salary, and the leader sent 5000 yuan to singo's account, but the transaction was not submitted, and singo happened to check the account and found that the salary had been paid, which was 5000 yuan. I was very happy. Unfortunately, the leader found that the amount of salary sent to Singo was 2,000 yuan, so he quickly rolled back the transaction. After modifying the amount, the transaction was submitted. In the end, the actual salary of Singo was only 2,000 yuan. Singo was happy.
The above situation occurs, that is, what we call dirty reads, two concurrent transactions, "transaction A: the leader pays singo", "transaction B: singo query salary account", transaction B read the data that has not yet been submitted by transaction A .
When the isolation level is set to Read uncommitted, dirty reads may occur. For how to avoid dirty reads, please see the next isolation level.
Read committed
Singo took the salary card to spend, the system read that the card did indeed have 2,000 yuan, and at this time her wife also happened to transfer money online, transferred the 2,000 yuan of the singo salary card to another account, and submitted it before singo Affairs, when singo deducted money, the system checked that there was no money in singo's salary card, and the deduction failed. Singo was very puzzled. It was clear that there was money in the card, why...
The above situation occurs, that is, what we call non-repeatable reading, two concurrent transactions, "transaction A: singo consumption", "transaction B: singo's wife online transfer", transaction A reads the data in advance, and transaction B immediately follows The data is updated and the transaction is committed, and when transaction A reads the data again, the data has changed.
When the isolation level is set to Read committed, dirty reads are avoided, but non-repeatable reads may be caused.
The default level of most databases is Read committed, such as Sql Server, Oracle. How to solve the problem of non-repeatable reading, please see the next isolation level.
Repeatable read
When the isolation level is set to Repeatable read, non-repeatable reads can be avoided. When Singo takes the salary card to consume, once the system starts to read the salary card information (that is, the transaction starts), it is impossible for Singo's wife to modify the record, that is, Singo's wife cannot transfer money at this time.
Although Repeatable read avoids non-repeatable reads, phantom reads may also occur.
Singo's wife works in the banking department. She often checks Singo's credit card consumption records through the bank's internal system. One day, she was inquiring that the total credit card consumption amount of Singo (select sum(amount) from transaction where month = this month) was 80 yuan, and Singo happened to be outside at the cashier after eating Haisai and paying for it. 1000 yuan, that is, a new consumption record of 1000 yuan (insert transaction ...) is added, and the transaction is submitted, and then the wife of singo printed the details of the credit card consumption of singo that month on the A4 paper, but found that the total consumption was 1080 yuan , Singo’s wife was surprised, thinking that there was a hallucination, and that’s how the hallucinations occurred.
Note: The default isolation level of MySQL is Repeatable read.
Serializable serialization
Serializable is the highest transaction isolation level, and at the same time, the cost is the highest, the performance is very low, and it is generally rarely used. At this level, transactions are executed sequentially, which can not only avoid dirty reads and non-repeatable reads, but also avoid phantom reads.
Two, dirty reading, phantom reading, non-repeatable reading
1. Dirty read:
Dirty read refers to when a transaction is accessing data, and the data is modified, and this modification has not been submitted to the database, at this time, another transaction also accesses the data, and then uses the data .
2. Non-repeatable reading:
refers to reading the same data multiple times in a transaction. Before this transaction is over, another transaction also accesses the same data. Then, between the two read data in the first transaction, due to the modification of the second transaction, the data read twice in the first transaction may be different. In this way, the data read twice in a transaction is different, so it is called non-repeatable read. (That is, the same data content cannot be read)
For example, an editor reads the same document twice, but between the two readings, the author rewrites the document. When the editor reads the document for the second time, the document has been changed. The original read cannot be repeated. This problem can be avoided if the editor can read the document only after the author has finished writing.
3. Phantom read:
refers to a phenomenon that occurs when the transaction is not executed independently, for example, the first transaction modifies the data in a table, and this modification involves all data rows in the table. At the same time, the second transaction also modifies the data in this table. This modification is to insert a new row of data into the table. Then, the user who operates the first transaction in the future will find that there are still unmodified data rows in the table, as if
an illusion occurred.
For example, an editor changes the document submitted by the author, but when the production department merges its changes into the master copy of the document, it is discovered that the author has added new unedited material to the document. This problem can be avoided if no one can add new material to the document before the editor and the production department finish processing the original document.