Four isolation levels of Mysql

What is a transaction A

transaction is a rigorous series of operations in an application, all of which must complete successfully or all changes made in each operation will be undone. That is, transactions are atomic, and a series of operations in a transaction either all succeed or none of them are done.

There are two types of end of transaction. When all the steps in the transaction are successfully executed, the transaction is committed. If one of the steps fails, a rollback operation occurs, undoing all operations up to the start of the transaction.

ACID

transactions of transactions have four characteristics: Atomicity, Consistency, Isolation, and Durability. These four features are referred to as ACID features for short.

1. Atomicity. Transaction is the logical unit of work of the database. All operations included in the transaction are either done or not done

. 2. Consistency. The result of transaction execution must be to change the database from one consistent state to another consistent state. So a database is said to be in a consistent state when it only contains the results of successful transaction commits. If a failure occurs during the operation of the database system, some transactions are forced to be interrupted before they are completed, and some of the modifications made to the database by these unfinished transactions have been written to the physical database. At this time, the database is in an incorrect state, or inconsistent state.

3. Isolation. The execution of a transaction cannot be interfered with by other transactions. That is, the operations and data used within a transaction are isolated from other concurrent transactions, and concurrently executed transactions cannot interfere with each other.

4. Sustainability. Also known as permanent, once a transaction is committed, its changes to the data in the database should be permanent. Other operations or failures that follow should not have any effect on the result of its execution.

Four isolation levels of Mysql

The SQL standard defines four types of isolation levels, including some specific 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 in practical applications because its performance is not much better than other levels. Read uncommitted data, also known as dirty read (Dirty Read).

Read Committed

This is the default isolation level for most database systems (but not MySQL's default). It satisfies the simple definition of isolation: a transaction can only see changes made by committed transactions. This isolation level also supports the so-called non-repeatable read (Nonrepeatable 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 (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. In theory, though, this leads to another thorny problem: Phantom Read. Simply put, phantom read means that when a user reads a range of data rows, another transaction inserts a new row in the range. Phantom" line. InnoDB and the Falcon storage engine solve this problem through the Multiversion Concurrency Control (MVCC, Multiversion Concurrency Control) mechanism.

Serializable (serializable)

This is the highest isolation level, and it solves the problem of phantom reads by forcing transaction ordering so that they cannot conflict with each other. In short, it adds a shared lock on each read data row. At this level, a lot of timeouts and lock contention can result.

These four isolation levels are implemented by different lock types. If the same data is read, problems are prone to occur. For example:

Drity Read: A transaction has updated a piece of data, and another transaction has read the same piece of data at this time. For some reason, the previous RollBack operation will be read by the latter transaction. The data will be incorrect.

Non-repeatable read (Non-repeatable read): The data is inconsistent between two queries of a transaction, which may be the original data updated by a transaction inserted between the two queries.

Phantom Read: The number of data is inconsistent in the two queries of a transaction. For example, one transaction queried several columns of (Row) data, while another transaction inserted new columns of data at this time. In the next query, the transaction will find that there are several columns of data that it did not have before.

In MySQL, these four isolation levels are implemented, which may cause problems as follows:

 

  

Testing the isolation level of Mysql

Next , we will use the MySQL client program to test these isolation levels separately.

The test database is demo and the table is test; table structure:

 

  

the two command line clients are A and B respectively; constantly change the isolation level of A, and modify the data on the B side.

(1) Set the isolation level of A to read uncommitted (uncommitted read)

 

  

A: Start the transaction, and the data is in the initial state

 

  

B: Start the transaction, update the data, but not submit

 

  

A: Read the data again and find that the data has been has been modified, which is called a "dirty read"

 

  

B: Rollback transaction

 

  

A: Read the data again and find that the data has returned to the initial state.

 

  

After the above experiments, it can be concluded that transaction B has updated a record, but has not committed it. At this time, transaction A can query the uncommitted record. cause dirty reads. Uncommitted read is the lowest isolation level.

(2) Set the transaction isolation level of client A to read committed (read committed)

 

  

A: start the transaction, and the data is in the initial state at this time

 

  

B: start the transaction, update the data, but not commit

 

  

A: read the data again and find The data has not been modified

 

  

B: Commit transaction

 

  

A: Read the data again and find that the data has changed, indicating that the modification submitted by B has been read by A in the transaction, which is the so-called "non-repeatable read".

 

  

The above experiments can be concluded In conclusion, the committed read isolation level solves the problem of dirty reads, but the problem of non-repeatable reads occurs, that is, the data of transaction A is inconsistent between two queries, because transaction B has updated a piece of data between the two queries. Read committed only allows reading committed records, but does not require repeatable reads.

(3) Set the isolation level of A to repeatable read (repeatable read)

 

  

A: Start the transaction, and the data is in the initial state

 

  

B: Start the transaction, update the data, but not submit

 

  

A: Read the data again, and find that the data is not Modified

 

  

B: Commit transaction

 

  

A: Read the data again, and find that the data has not changed, which means that this time it can be read repeatedly

 

  

B: Insert a new data, and submit

 

  

A: Read the data again, and find that the data has not happened yet Change, although it can be read repeatedly, but it is found that the read data is not the latest data, this is the so-called "phantom read"

 

  

A: Submit this transaction, read the data again, and find that the reading is normal

 

  

It can be concluded from the above experiments that the repeatable read isolation level only allows to read committed records, and during the period when a transaction reads a record twice, other transaction departments update the record. But the transaction is not required to be serializable with other transactions. For example, when a transaction can find records updated by a committed transaction, but phantom read problems may occur (note that it is possible, because databases implement different isolation levels). Like the above experiments, there is no problem of data phantom reading.

(4) Set the isolation level of A to Serializable

 

  

A: Start the transaction, and the data is in 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 been committed, only Can wait (at this time, B may wait for a timeout)

 

  

A: Commit transaction

 

  

B: It is found that the insertion is successful and the

 

  

serializable completely locks the field. If a transaction queries the same data, it must wait until the previous transaction is completed and unlocked. It is a complete isolation level, which will lock the corresponding data table, so there will be efficiency problems.