Four isolation levels in MYSQL

I recently learned about the isolation level of Mysql, recorded it, and integrated resources. Don’t blame me for writing mistakes. There may be errors.


What are dirty reads, non-repeatable reads, and phantom reads?


--Dirty Read: One transaction reads data that has not yet been committed by another transaction.

--Non-repeatable Read: A transaction reads the same data multiple times, but during the transaction process, other transactions modify the data, causing the read data to be inconsistent.

--Phantom Read: A transaction reads the same data range multiple times, but during the transaction process, other transactions insert or delete data in the range, causing the read data set to change.


Four isolation levels


Read Uncommitted: This is the lowest isolation level. At this level, a transaction can read modifications made by other uncommitted transactions. This can lead to problems such as dirty reads, non-repeatable reads, and phantom reads.

Read Committed: At this level, a transaction can only read committed data. This avoids dirty read problems, but non-repeatable reads and phantom reads may still occur.

Repeatable Read: At this level, the data set read at the beginning of a transaction will remain consistent even if other transactions modify the data. This avoids dirty read and non-repeatable read problems, but phantom read problems may still occur.

Serializable: This is the highest isolation level. At this level, transactions are executed serially, ensuring that no concurrency issues arise. It is implemented by adding a shared lock to the read data and an exclusive lock to the written data. The serialization isolation level can avoid dirty reads, non-repeatable reads, and phantom reads, but it also brings the highest concurrency performance overhead.

It should be noted that a higher isolation level will bring more lock competition and resource occupation, thus affecting concurrency performance. Therefore, when choosing an isolation level, you should weigh it against your application's specific needs and concurrency performance requirements. By default, most database systems use the Read Committed isolation level.


What is the default isolation level of mysql?


MySQL's default isolation level is REPEATABLE READ. Repeatable read is MySQL's default transaction isolation level, which provides higher data consistency. Under the repeatable read isolation level, the data set read by a transaction is fixed. Even if other transactions modify the data, the results read by the current transaction remain consistent with those at the beginning of the transaction.

Under the repeatable read isolation level, MySQL uses multi-version concurrency control (MVCC) to achieve transaction isolation. MVCC prevents problems such as non-repeatable reads and dirty reads by saving snapshots of data at different points in time and using row-level locks.

Although the repeatable read isolation level provides higher data consistency, it may also cause phantom read problems. Phantom reading means that in a transaction, when the same query is read multiple times, the result set obtained may change, that is, data inserted or deleted by other transactions is read.

If a higher isolation level is required, the isolation level can be set to SERIALIZABLE, but this may have a certain impact on concurrency performance. Choosing the appropriate isolation level requires trade-offs based on the needs and characteristics of the application.


Locks in isolation levels


In MySQL, locks are mainly divided into two categories: Shared Lock and Exclusive Lock. When a transaction reads data, it can acquire a shared lock, and multiple transactions can hold shared locks at the same time, thus achieving concurrency in reading data. When a transaction modifies data, it needs to obtain an exclusive lock. Only the transaction holding the exclusive lock can modify the data. This can avoid data inconsistency caused by multiple transactions modifying the same row of data at the same time.

Locks in transactions can be used to control the following situations:

Avoid dirty reads: When a transaction modifies certain data, by adding an exclusive lock, other transactions cannot read the data in the modified intermediate state, and the final result can be read only after the transaction is committed. (After adding an exclusive lock, the data cannot be locked again, and the data can be queried but cannot be changed)

Prevent non-repeatable read: Through shared locks, the data read by one transaction will not be modified by other transactions during the transaction, ensuring the consistency of reading.

Prevent phantom read (Phantom Read): By locking the index range, it prevents other transactions from inserting or deleting qualified data during the transaction, ensuring the consistency of reading.

It should be noted that using a lock mechanism may have an impact on concurrency performance, especially in high-concurrency environments. Therefore, when designing database applications, it is necessary to select appropriate lock strategies and isolation levels based on business needs and performance requirements to balance data consistency and concurrency performance.

Guess you like

Origin blog.csdn.net/lfeishumomol/article/details/132143246