Article directory
Preface
How to control concurrency is one of the very important issues in the database field. In order to solve the problems caused by concurrency, MySQL has designed transaction isolation mechanism, lock mechanism, MVCC mechanism, etc., and uses a complete set of mechanisms to solve concurrency problems. This article mainly introduces transaction isolation mechanism.
1. What is a database transaction?
Transaction (abbreviated as tx), in the database, a transaction refers to a set of logical operations, which are either all executed or not executed at all, and are an indivisible unit of work. Transactions by 事务开始与结束之间执行的全部数据库操作组成.
Transactions have the following four characteristics, referred to as ACID:
1. Atomicity ( Atomicity)
transaction is an atomic operation unit, which is the smallest indivisible unit of work, just like atoms in chemistry, which modify data 要么全都执行，要么全都不执行.
2. Consistency ( Consistent)
Consistency means that a transaction must transform the database from one consistency state to another consistency state.
Consistency is also called integrity, which means that the execution of a transaction cannot destroy the consistency of the database. The data must remain consistent when the transaction is started and completed. This means that all relevant data rules must be applied to the transaction's modifications in order to persist 数据的完整性.
3. Isolation ( Isolation)
The database provides a certain isolation mechanism. When multiple transactions access concurrently, it ensures that the transactions are not affected by external concurrent operations “独立”环境执行. Of course, different isolation levels determine how "independent" they are.
4. After a durable ( Durable)
transaction is completed, it 数据的修改是永久性的can be maintained even if a system failure occurs.
Summary: Everyone can basically understand atomicity and persistence in seconds, and isolation is okay. Everyone can understand it after a little thought, which is the isolation level that I will talk about next. However, many people are confused by the official concept of consistency. In fact, It is to ensure the consistency and completeness of data when multiple transactions are concurrent. If you don’t understand, please read the following questions first.
2. Four types of problems caused by transaction concurrency
1. Dirty Reads:
Transaction A reads the data modified but not yet committed by transaction B, and then transaction B rolls back. Therefore, the operations performed by transaction A based on this data are invalid, that is, "dirty" data is read. (Data that should not actually exist), so it is called dirty reading.
2. Dirty write or lost update (Lost Update)
The first type of lost update: rollbackwhen a transaction is revoked, the updated data that has been submitted by other transactions 回滚is dropped.
The second type of lost update: commitwhen a transaction is submitted, the updated data that has been submitted by other transactions 覆盖is lost.
3. Non-Repeatable Reads:
In transaction A, the queried SQL is executed according to the same conditions, and the returned results are modified or deleted. This phenomenon is called "non-repeatable reads".
4. Phantom Reads:
In transaction A, the queried SQL is executed according to the same conditions, and there is new data (inserted by other transactions) in the returned results, as if an illusion has occurred. This is called "phantom reads" ".
Summary: Non-repeatable reading and phantom reading are easily confused. Non-repeatable reading focuses on modification or deletion, while phantom reading focuses on new additions. Regarding this conclusion, many bloggers on the Internet write that
non-repeatable reading focuses on modification, and phantom reading focuses on adding or deleting(including some well-known bloggers). Please note that deletion does not belong to phantom reading. I will demonstrate in the fourth paragraph. Ask for proof. In addition, I will arrange a separate article to introduce the MVCC mechanism later, and you will naturally understand the reason here.
3. 4 isolation levels of transactions
There are four isolation levels defined in the SQL standard. Each level specifies the modifications made in a transaction, which ones are visible within and between transactions, and which ones are invisible. Lower levels of isolation typically allow for higher concurrency and lower system overhead.
Possible problems for each isolation level are as follows:
| transaction isolation level | dirty read | non-repeatable read | phantom reading |
|---|---|---|---|
| Read Uncommitted (RU) | 可能 |
可能 |
可能 |
| ReadCommitted(RC) | impossible | 可能 |
可能 |
| Repeatable Read (RR) | impossible | impossible | 可能 |
| Serializable | impossible | impossible | impossible |
1. Read uncommitted (RU)
Modifications in a transaction, even if they are not committed, are visible to other transactions. Because they may cause dirty reads, they are generally rarely used in practical applications.
2. Read committed (RC)
Only the data modified and committed by transaction A will be visible to other transactions, so the problem of dirty reads is solved. The default isolation level of most database systems is read committed (like Oracle, PostgreSQL, SqlServer, but not Mysql).
3. Repeatable read (RR)
Mysql's default transaction isolation level. It ensures that the results of reading the same record multiple times in the same transaction are consistent, so it solves the problems of dirty reads and non-repeatable reads, but does not completely solve phantom reads.
4. Serializable
Serializable is the highest isolation level. It avoids the problems of dirty reads, non-repeatable reads and phantom reads mentioned earlier by forcing transactions to be executed serially. Simply put, serializability adds a lock on each row of data read, so it can cause a lot of timeouts and lock contention problems. This isolation level is rarely used in actual applications. This level should only be considered when it is very necessary to ensure data consistency and no concurrency is acceptable.
4. Mysql demonstrates 4 isolation levels
In MySQL, the InnoDB engine supports transactions, but the MyISAM engine does not support transactions, so the test environment for this article's experiment is: Windows 10 + MySQL5.7 + InnoDB.
Mysql5.7 can select @@tx_isolation;be viewed through command statements:
mysql> select @@tx_isolation;
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+
Commands to set 4 isolation levels:
set tx_isolation='read-uncommitted';
set tx_isolation='read-committed';
set tx_isolation='repeatable-read';
set tx_isolation='serializable';
Start transaction:
begin;
Submit transaction:
commit;
Rollback transaction:
rollback;
1. Read Uncommitted (RU)
set tx_isolation='read-uncommitted';
select @@tx_isolation;
begin;
Verify dirty reads
2. Read submitted (RC)
set tx_isolation='read-committed';
select @@tx_isolation;
begin;
Verify that dirty reads are resolved and non-repeatable reads exist
Verify phantom reads
3. Repeatable Read (RR)
set tx_isolation='repeatable-read';
select @@tx_isolation;
begin;
Verification solves dirty reads and non-repeatable reads
. As mentioned above 不可重复读侧重于修改或删除, please see the screenshot below for verification.
Verifying phantom reading
The RR level of Mysql solves the phantom reading problem to a certain extent, but it is not thorough enough. Why do you say this? Again, you need to understand the MVCC mechanism in depth. This will be arranged in a separate article, so stay tuned!
4. Serializable
set tx_isolation='serializable';
select @@tx_isolation;
begin;
If blocked for a long time, the lock wait timeout will eventually occur and an exception will be thrown: ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction is executed
in transaction A, and the result will be the same, blocking until other transactions are completed or timeout is thrown. The same exception occurs.
The same is true for update, as shown in the following figure:
Summarize
Through this article we have explained in detail:
- 4 major characteristics of transactions: ACID
- Four types of problems caused by transaction concurrency: dirty reads, dirty writes, non-repeatable reads, and phantom reads
- There are 4 isolation levels for transactions: read uncommitted, read committed, repeatable read, and serialized
- Demonstration of 4 isolation levels provided by Mysql
We will see the remaining MySQL lock mechanism and MVCC mechanism below!
If you feel good, please follow me Tiangang gg to share more interesting information. Home page address: https://blog.csdn.net/scm_2008
Everyone's " collection + like + follow + comment " is the biggest motivation for my creation!
Related blog posts:
MySQL transaction isolation mechanism
MySQL transaction isolation mechanism
Detailed explanation of MySQL transaction isolation level
Thorough interpretation of MySQL's repeatable reading, phantom reading and implementation principles