1. What is a transaction
Transaction refers to an operation consisting of multiple steps, either all succeed or all fail. For example, our commonly used transfer function, assuming that account A transfers money to account B, involves two operations:
(1) debiting money from account A;
(2) adding the same amount of money to account B.
Because they are two independent operations, there may be cases where one succeeds and the other fails. But because in this scenario, the transaction must be guaranteed, that is, either succeed at the same time or fail at the same time (one failure needs to be rolled back), there cannot be a situation where the deduction of money from the A account is successful, but the addition of the same amount of money to the B account fails.
2. Four characteristics of database transactions
Database transactions have four attributes: atomicity, consistency, isolation, and durability. These four properties are often referred to as ACID properties. Atomicity : The transaction is executed as a whole, and the operations on the database included in it are either all executed or none of them are executed.
Consistency : A transaction should ensure that the state of the database changes from one consistent state to another. The meaning of a consistent state is that the data in the database should satisfy the integrity constraints.
Isolation : When multiple transactions are executed concurrently, the execution of one transaction should not affect the execution of other transactions, and multiple concurrent transactions should be isolated from each other.
Durability : Once a transaction is committed, its modifications to the database should be permanently stored in the database.
After introducing the four major characteristics (ACID) of transactions, the focus is on the isolation of transactions (Isolation).
3. Transaction isolation
3.1 How can a transaction interfere with other transactions?
For example, suppose there is an InnoDB table: t(id PK, name);,
There are three pieces of data in the table:
1 little red
2 Xiaoming
3 Xiao Wang
Open two transactions A and B.
Dirty read: Read and read uncommitted data, transaction A updates data uncommitted, transaction B reads data, transaction A commits, uncommitted data is dirty read, dirty data
Non- repeatable read: Transaction B reads data twice, and transaction A modifies the data during the two readings , and the data read by transaction B is different. The impact of committed transaction A on transaction B, this effect is called "nonrepeatable read" (Nonrepeatable Read)
Phantom reading: Transaction B reads data twice. During the two readings, transaction A adds data, and the sets read by transaction B are different. This time it is the impact of committed transaction A on transaction B, which is called "phantom read". The phantom reading process looks similar to non-repeatable reading. The phantom reading emphasizes the addition and deletion of a collection, not the modification of a single piece of data.
The difference between dirty reads and non-repeatable reads: Dirty reads mean that a transaction reads uncommitted dirty data from another transaction, while non-repeatable reads read data committed by a previous transaction.
The similarities and differences between non-repeatable reads and phantom reads: both read another transaction that has already been committed (this is different from dirty reads), the difference is that non-repeatable reads query the same data item, and phantom reads target It is a batch of data as a whole (such as adding and deleting data).
In addition to the above, there is also a problem of lost updates:
1. Lost update (Lostupdate)
Two transactions are updated at the same time, and the rollback of the second transaction will overwrite the data updated by the first transaction, resulting in loss of updates
2. Second lost updates problem
Both transactions read the data and update it at the same time. The first transaction update failed because it was overwritten by the second transaction.
As you can see, concurrent transactions may lead to other transactions:
(1) Dirty read;
(2) Non-repeatable reading;
(3) phantom reading;
(4) Update lost
3.2 Transaction isolation level
The SQL92 standard defines four isolation levels:
(1) Read Uncommitted (Read Uncommitted); solve update loss
(2) Read Committed ( Read Committed, RC); solve dirty read and update loss
(3) Repeatable Read (Repeated Read, RR); solve non-repeatable read, dirty read and update loss
(4) Serializable ; sequential execution, one by one, to solve all problems
Issues that may arise in concurrent transactions under various isolation levels:
In the MySQL database, the above four isolation levels are supported, and the default level is Repeatable read (repeatable read); at the RR level, InnoDB solves the problem of phantom reading by locking. The next article will talk about updating the mysql lock mechanism in detail.