Transfer from: https://www.jianshu.com/p/8d735db9c2c0
What is a transaction
A transaction is a series of strict operations in an application. All operations must be completed successfully, otherwise all changes in each operation will be cancelled, that is, the transaction is atomic, and a series of operations in a transaction are either all successful or not done at all.
There are two types of transaction endings. When all steps in the transaction are successfully executed, the transaction commits. If one of the steps fails, a rollback operation will occur, undoing all operations from before to the beginning of the transaction.
ACID of the transaction
Transactions have four characteristics: atomicity, consistency, isolation and durability. These four features are referred to as ACID features for short.
Atomicity: A transaction is the logical unit of work of the database. All operations contained in the transaction are either done or not done.
Consistency: The result of transaction execution must be to change the database from one consistent state to another consistent state. Therefore, when the database only contains the results of successful transaction submission, the database is said to be in a consistent state.
Isolation: There is no interference between one transaction and other transactions.
Persistence: Once a transaction is committed, its changes to the data in the database should be permanent. The following other operations or failures should not have any impact on other execution results.
The four isolation levels of Mysql
The SQL standard defines 4 types of isolation levels, including some specific rules and rules to limit which changes inside and outside the transaction are visible and which are invisible. Low-level isolation levels generally support higher concurrent processing
and have lower system overhead.
Read Uncommitted (read uncommitted content)
At this isolation level, all transactions can see the execution results of other uncommitted transactions. This isolation level is rarely used to implement applications, because its performance is not much better than other levels. Reading uncommitted data is also called dirty read.
Read Committed (read submitted content)
This is the default isolation level of most database systems (but not the mysql default). It satisfies the simple definition of isolation; a transaction can only see the changes made by the committed transaction. This isolation level also supports the so-called non-repeatable read, because other instances of the same transaction may have new commits during the processing of the instance, so the same select may return different results.
Repeatable Read
This is MySQL's default transaction isolation level, which ensures that multiple instances of the same transaction will see the same data rows when reading data concurrently. But in theory, this leads to another tricky problem, phantom reading. Simply put, a phantom read means that when the user reads a certain range of data rows, another transaction inserts a new row in the range, and when the user reads a certain range of data rows, another transaction is in the same range. A new row is inserted in the range. When the user reads the data row in the range again, a new phantom row will be found.
Serializable (serializable)
This is the highest isolation level. It solves the phantom reading problem by forcing transactions to make it impossible to conflict with each other. In short, it is to add a shared lock to each read data row. This several times may lead to a lot of timeouts and lock contention.
These four isolation levels are implemented using different lock types. If the same data is read, problems are prone to occur, such as:
Dirty read: A transaction has updated a piece of data, and another transaction reads the same piece of data at this time. For some reasons, the previous RollBack operation is performed, and the data read by the next transaction will be incorrect of.
Non-repeatable read: The data is inconsistent in the two queries of a transaction. This may be the original data updated by a transaction inserted between the two queries.
Phantom read: The data is inconsistent in the two queries of a transaction. For example, one transaction queries several columns of data, while another transaction inserts new columns of data at this time. The previous transaction is in the next query. There are several columns of data that have not been queried. If you insert data at this time and another transaction insert, an error will be reported.
Test the isolation level of Mysql
Next, we will use the MYSQL client program to test these isolation levels. The
test database is demo and the table structure: the
two command line clients are A and B respectively. Constantly change the isolation level of A, modify the data on the B side
Set the isolation level of A to read uncommitted (read uncommitted)
A: Start the transaction, the data is in the initial state at this time
B: Start the transaction, update the data, but do not submit
A: Read the data again, find that the data has been modified, this is the so-called "dirty read"
B: Roll back the transaction
A : Read the data again and find that the data has changed back to the initial state.
After the above experiment, it can be concluded that transaction B updated a record but not submitted. At this time, transaction A can query the uncommitted records. Cause dirty reading phenomenon. Uncommitted read is the lowest isolation level.
Set the transaction isolation level of client A to read committed (read committed)
A: Start the transaction, the data is in the initial state at this time
B: Start the transaction, update the data, but do not submit
A: Read the data again, find that the data has not been modified
B: Submit the transaction
A: Read the data again, find that the data has changed, Explain that the modification submitted by B was read by A in the transaction. This is the so-called "non-repeatable read".
After the above experiment, it can be concluded that the submitted read isolation level solves the problem of dirty reads, but there are non-repeatable reads. The problem is that the data of transaction A is inconsistent in the two queries, because transaction B updated a piece of data between the two queries. Read submitted is only allowed to read the submitted records, but it is not required to read repeatedly.
Set the isolation level of A to repeatable read (repeatable read)
A: Start the transaction, the data is in the initial state at this time
B: Start the transaction, update the data, but do not submit
A: Read the data again, find that the data has not been modified
B: Submit the transaction
A: Read the data again, find that the data still has not occurred Change, which means that this time you can read
B: insert a new piece of data, and submit
A: read the data again, find that the data is still unchanged, although you can repeat the read, but found that the read is not the latest data, this It is the so-called "phantom reading"
A: Submit this transaction, read the data again, and find that the reading is normal
Set the isolation level of A to Serializable (Serializable)
A: Start the transaction, the data is the initial state at this time
B: It is found that B has entered the waiting state at this time, because the transaction of A has not yet been submitted and can only wait (at this time, B may have a waiting timeout)
A: Submit the transaction
B: It is found that the insert is successful and the
serializable completely locks the field, if one Transaction to query the same data must wait until the previous transaction is completed and unlocked. It is a complete isolation level, and the corresponding data table will be locked, so there will be efficiency problems.