MySQL transaction isolation level

The SQL standard defines four isolation levels, including some specific rules to limit which changes inside and outside the transaction are visible and which are invisible. Low-level Isolation generally supports higher concurrent processing and 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 no better than other levels. Read uncommitted data, also known as dirty read ).

Read committed (read submitted content)

This is the default isolation level for most database systems (but not for MySQL ). 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 nonrepeatable read, because other instances of the same transaction may have a new commit during the processing of this instance, so the same select may return different results.

Repeatable read (repeable)

This is the default transaction isolation level of MySQL. It ensures that multiple instances of the same transaction will see the same data rows when reading data concurrently. However, theoretically, this will lead to another tricky problem: phantom read ). In short, phantom read refers to when a user reads data in a certain range, another transaction inserts a new row in this range. When the user reads data in this range, there will be a new Phantom line. The InnoDB and Falcon storage engines use multi-version concurrency control (MVCC, multiversion
Concurrency Control.

Locking a row can control the display after the update and delete operations are submitted. However, the results after the insert operation is submitted cannot be controlled.

Serializable (serializable) 

This is the highest isolation level. It forces transaction sorting to make it impossible to conflict with each other, thus solving the phantom read problem. In short, it adds a shared lock to each read data row ??? (Yes ?) At this level, there may be a lot of timeout and lock competition.

The four isolation levels adopt different lock types. If the same data is read, problems may occur. For example:

Dirty read: a transaction has updated the data, and another transaction has read the same data at this time. For some reason, the previous rollback operation is performed, the data read by the other transaction is incorrect.

Non-Repeatable read: the data in the two queries of a transaction is inconsistent. This may be because the original data updated by a transaction is inserted in the two queries.

Phantom read: the number of data records in two queries of a transaction is inconsistent. For example, a transaction queries several rows of data, another transaction inserts several new columns of data at this time. In the subsequent query, the previous transaction will find that several columns of data are not at the beginning. This problem may only occur because the implementation methods are different and some do not.

In addition, newly added data may appear, but not modified data.

In MySQL, these four isolation levels are implemented, which may cause the following problems:

Next, we will test several isolation levels using MYSQL client programs. The test database and table are Tx. The table structure is as follows:

ID	Int
Num	Int

The two command line clients are A and B respectively. The isolation level of A is constantly changed and data is modified on the B side.

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

Before B updates data:

Client:

B. Update Data:

Client B:

Client:

After the experiment above, we can conclude that transaction B updates a record but does not commit it. At this time, transaction a can query uncommitted records. This causes dirty reading. Uncommitted read is the lowest isolation level.

(2) set the transaction isolation level of client a To Read committed (committed read)

Before B updates data:

Client:

B. Update Data:

Client B:

Client:

After the above experiment, we can conclude that the committed read isolation level solves the dirty read problem, but the problem of non-repeated read occurs, that is, transaction a's data in the two queries is inconsistent, because transaction B updates a piece of data between the two queries. Committed read: only submitted records can be read, but repeat is not required.

(3 ), Set the isolation level of A to Repeatable read (Repeatable read)

Before B updates data:

Client:

B. Update Data:

Client B:

Client:

B. insert data:

Client B:

Client:

From the above experiments, we can conclude that the Repeatable read isolation level only allows reading committed records, and that during the two reads of one record by one transaction, other departments will update this record. However, this transaction does not require serializability with other transactions. For example, when a transaction can find a record updated by a committed transaction, but it may cause phantom read problems (note that it is possible because the database has different isolation-level implementations, innoDB does not have phantom reading ). As in the above experiments, there is no phantom data reading problem.

( 4 ),Set the isolation level of ASerializable)

Start the transaction at Client A and insert a record at client B.

Transaction:

Transaction side B:

At this time, the isolation level of transaction a is set to serializable. After the transaction starts, it is not committed, so transaction B can only wait.

Transaction a submit the transaction:

Transaction

Transaction side B

Serializable completely locks the field. If a transaction is used to query the same data, it must wait until the previous transaction is completed and unlocked. Is a complete isolation level, it will lock the corresponding data table, so it will be efficient.

Reproduced http://xm-king.iteye.com/blog/770721