[Transaction] MySQL transaction characteristics, isolation level

1. What is a transaction

It is easy to understand that during the execution of a transaction, we have performed several operations on the database and executed multiple commands. After the transaction is over, these commands either all execute successfully or all fail to execute. Other results exist.

2. Characteristics of transactions

Atomicity : A transaction itself is atomic, which means that the operations in the transaction are either all completed or all fail.
Consistency : Before and after the execution of the transaction, the data remains consistent. For example, in the transfer business, regardless of whether the transfer succeeds or fails, the total amount of the payee and payer remains unchanged.
Isolation : When accessing the database concurrently, the operations between multiple transactions should not affect each other.
Persistence : After a transaction is committed, the changes to the data in the database are permanent.

3. Transaction isolation level

The following four isolation levels are incremented:

Read Uncommitted : A transaction can read data in other uncommitted transactions.
Read committed : A transaction can only read the data of other transactions that have been committed. If other transactions are not committed, they cannot read the data in these transactions.
Repeatable reading : A certain data read by a transaction during its startup phase is the same until the data read at the end of the transaction.
Serialization : The highest isolation level, fully compliant with the ACID isolation level. All transactions are executed one by one in turn, so that there is no possibility of interference between transactions.

You can better understand it through the picture below (picture from: Geek Time Lin Xiaobin):

insert image description here

The scenario is as follows: Assume that only one data in a table is 1, and transaction A and transaction B operate the table concurrently.
First, transaction A and transaction B start the transaction at the same time, transaction A first queries the data to get 1, then transaction B also queries the data to get 1 and then changes it to 2, then transaction A queries the data again, we assume it is V1; Then transaction B commits, transaction A queries the data for the second time to get V2, then transaction A commits, and after the commit, queries the data for the third time to get V3.
Look at the number of V1, V2, and V3 under different isolation levels (the time sequence of operations is from top to bottom in the figure).

If the isolation level is "read uncommitted" : under this isolation level, transaction A can read the uncommitted data of transaction B, and V1 is read when transaction B is uncommitted, so V1 is 2, then V2 and V3 are also 2.
If the isolation level is "read committed" : under this isolation level, transaction A cannot read the uncommitted data of transaction B, so V1 is still 1, and V2 is read by transaction A after transaction B commits, so V2 is 2, V3 is also 2.
If the isolation level is "repeatable read" : under this isolation level, transaction A reads the same data in its entire transaction, so V1 and V2 are the same, both are 1, and V3 is 2.
If the isolation level is serialization : when transaction B executes "change 1 to 2", it will be locked. Transaction B cannot continue until transaction A commits. So from the perspective of A, the values ​​of V1 and V2 are 1, and the value of V3 is 2.

Guess you like

Origin blog.csdn.net/m0_52373742/article/details/122793500