This article is reproduced, the original address: http://singo107.iteye.com/blog/1175084
There are four isolation levels of database transactions, which are Read uncommitted, Read committed, Repeatable read, and Serializable from low to high. These four levels can solve the problems of dirty read, non-repeatable read, and phantom read one by one.
√: may appear ×: will not appear
| dirty read | non-repeatable read | hallucinations | |
| Read uncommitted | √ | √ | √ |
| Read committed | × | √ | √ |
| Repeatable read | × | × | √ |
| Serializable | × | × | × |
Note: We discuss the isolation level scenario, mainly in the case of multiple concurrent transactions, so the following explanations are all about transaction concurrency.
Read uncommitted
The company paid the salary, and the leader sent 5,000 yuan to singo's account, but the transaction was not submitted, and singo just went to check the account and found that the salary had arrived, and it was 5,000 yuan, very happy. But unfortunately, the leader found that the salary amount paid to singo was wrong, it was 2,000 yuan, so he quickly rolled back the transaction, revised the amount, and submitted the transaction.
The above situation occurs, that is, what we call dirty reads, two concurrent transactions, "transaction A: leader pays singo salary", "transaction B: singo queries salary account", transaction B reads the data that transaction A has not yet submitted. .
Dirty reads may occur when the isolation level is set to Read uncommitted. For how to avoid dirty reads, see the next isolation level.
Read committed
Singo took the salary card to consume, and the system read that there was indeed 2,000 yuan in the card. At this time, her wife just happened to transfer money online, and transferred the 2,000 yuan from the Singo salary card to another account, and submitted it before Singo. Transaction, when singo deducted money, the system checked that singo's salary card had no money, the deduction failed, singo was very puzzled, obviously there was money in the card, why...
The above situation occurs, that is, what we call non-repeatable read, two concurrent transactions, "transaction A: singo consumption", "transaction B: singo's wife online transfer", transaction A reads the data in advance, and transaction B 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 read, please see the next isolation level.
Repeatable read Repeatable read
Non-repeatable reads can be avoided when the isolation level is set to Repeatable read. 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 reads avoid non-repeatable reads, phantom reads are still possible.
Singo's wife works in the banking department, and she often checks Singo's credit card consumption records through the bank's internal system. One day, she was inquiring that the total consumption amount of Singo's credit card in the current month (select sum(amount) from transaction where month = this month) was 80 yuan, and Singo happened to pay for the bill at the cashier after eating haisai outside. 1,000 yuan, that is, a new consumption record of 1,000 yuan (insert transaction ... ) was added, and the transaction was submitted. Then Singo's wife printed the details of Singo's credit card consumption in the month on A4 paper, but found that the total consumption was 1,080 yuan. , Singo's wife was very surprised, thinking that there was a hallucination, and the hallucinations happened like this.
Note: The default isolation level of MySQL is Repeatable read.
Serializable serialization
Serializable is the highest transaction isolation level, but also has the highest cost, low performance, and is generally rarely used. At this level, transactions are executed sequentially, which can not only avoid dirty reads, non-repeatable reads, but also phantom reads.