Read Uncommitted
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. Reading uncommitted data is also known as 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 could lead 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:
Next, we will use the MySQL client program to test several isolation levels. The test database is test, and the table is tx; table structure:
id int
num
int
The two command line clients are A and B respectively; the isolation level of A is constantly changed, and the data is modified on the B side.
(1) Set the isolation level of A to read uncommitted (uncommitted read)
Before B does not update the data:
Client A:
B updates the data:
Client B:
Client A:
After the above experiments, it can be concluded that transaction B has updated a record, but it has not been committed. At this time, transaction A can query Record not submitted. cause dirty reads. Uncommitted read is the lowest isolation level.
(2) Set the transaction isolation level of client A to read committed (read committed)
Before B does not update the data:
client A:
B updates data:
client B:
client A:
After the above experiments, we can get It is concluded that 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 the 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)
Before B does not update the data:
client A:
B updates data:
client B:
client A:
B inserts data:
client B:
client Terminal A:
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. The
A side opens the transaction, and the B side inserts a record.
Transaction A side:
transaction B side:
because the isolation level of transaction A is set to serializable at this time, the transaction starts. After that, it is not committed, so transaction B can only wait.
Transaction A commits the transaction:
transaction A side
transaction B side
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.
quote
http://xm-king.iteye.com/blog/770721