There are four isolation levels of database transactions, from low to high, they are Read uncommitted, Read committed, Repeatable read, and Serializable. Moreover, dirty reads, non-repeatable reads, and phantom reads may occur in concurrent operations of transactions. The following examples illustrate their concepts and connections.
Read uncommitted
Read uncommitted, as the name implies, is that a transaction can read the data of another uncommitted transaction.
Example: The boss wants to pay the programmer, and the programmer's salary is 36,000/month. However, when the salary was paid, the boss accidentally pressed the wrong number, and it was 39,000/month. The money has been credited to the programmer's account, but the transaction has not been submitted. At this moment, the programmer went to check his salary for this month. I found that it was 3,000 yuan more than usual, and I thought I was very happy with the salary increase. But the boss found out in time that it was wrong, and immediately rolled back the transaction that was almost submitted, changed the number to 36,000 and submitted it again.
Analysis: The actual programmer's salary this month is still 36,000, but the programmer sees 39,000. What he sees is the data when the boss has not committed the transaction. This is dirty reading .
So how to solve dirty reading? Read committed! Read commit, can solve the dirty read problem.
Read committed
Read commit, as the name implies, means that a transaction cannot read data until another transaction commits.
Example: The programmer took his credit card to enjoy life (of course, the card was only 36,000), when he paid the bill (the programmer's affairs were turned on), the charging system detected in advance that his card had 36,000, at this time! ! The programmer's wife has to transfer all the money for household use and submit it. When the charging system is ready to deduct the money, it checks the amount in the card and finds that there is no money left ( the second check of the amount will of course wait for the transaction to be submitted by the wife to transfer the amount ). Programmers will be very depressed, obviously the card is rich...
Analysis: This is the read commit. If there is a transaction to update the data (UPDATE), the read operation transaction must wait for the update operation transaction to be committed before reading the data, which can solve the dirty read problem. But in this case, two identical queries within a transaction scope return different data , which is non-repeatable read .
So how to solve the possible non-repeatable read problem? Repeatable read!
Repeatable read
Repeated read, that is, when starting to read data (transaction open), modification operations are no longer allowed
Example: The programmer enjoys life with his credit card (of course, the card is only 36,000), when he pays the bill ( the transaction is opened, and the UPDATE modification operation of other transactions is not allowed ), the charging system detects in advance that there is 36,000 in his card. . At this time his wife could not transfer the amount. The payment system will then deduct the payment.
Analysis: Repeated reads can solve the problem of non-repeatable reads. Writing here, it should be understood that the non-repeatable read corresponds to the modification, that is, the UPDATE operation . But there may also be phantom read issues. Because the phantom read problem corresponds to an INSERT operation, not an UPDATE operation .
When will hallucinations occur?
Example: The programmer went to consume one day and spent 2,000 yuan, and then his wife went to check his consumption record today (full table scan FTS, wife's transaction was turned on), and saw that it really cost 2,000 yuan, right here At that time, the programmer spent 10,000 to buy a computer, that is, a new consumption record was added to INSERT and submitted. When the wife printed the programmer's consumption record list (submitted by the wife's affairs), she found that she spent 12,000 yuan, which seemed to have hallucinations. This is hallucination.
So how to solve the phantom reading problem? Serializable!
Serializable serialization
Serializable is the highest transaction isolation level. At this level, transactions are serialized and executed sequentially , which can avoid dirty reads, non-repeatable reads and phantom reads. However, this transaction isolation level is inefficient and consumes database performance, so it is generally not used.
It is worth mentioning that the default transaction isolation level of most databases is Read committed, such as Sql Server, Oracle. Mysql's default isolation level is Repeatable read.