MVCC mechanism and four transaction isolation levels
What is multi-version concurrency control (MVCC: multi-version concurrency control)
- MVCC definition: Multi-version concurrent control system. It can be considered a variant of row-level lock, which can avoid locking operations in more cases.
- Role: Avoid some locking operations and improve concurrent performance.
- Realization: By saving the creation time and expiration time or deletion time of the row (they are hidden) behind each row of records, these two times are actually the version number of the system. Every time a new transaction is started, the version number is automatically increased.
- Specific principle
4.1) select: the innoBD query will check the following two conditions: one is that the version number of the data row is earlier than the version number of the current transaction; the other is the delete version number of the row, either none or greater than the version number of the current transaction .
4.2) insert/delete: InnoDB uses the current system version number as the version number of the newly inserted (deleted) data row.
4.3) update: first insert a new row of data, and use the current system version number as the row version number, and the current system version number as the deleted version number of the original row. When updating the primary key, the clustered index and the ordinary index will produce two versions; when updating the non-primary key, as long as the ordinary index will produce two versions - Note: MVCC only works under the two isolation levels of read committed and repeatable read.
Snapshot read, current read
To understand the locking methods of the first four isolation levels, it is necessary to understand MVCC, snapshot read, and current read.
In MVCC concurrency control, read operations can be divided into two categories: snapshot read and current read.
Snapshot read, read the visible version of the record (maybe the historical version) without locking.
The current read is the latest version of the record, and the record returned by the current read will be locked to ensure that other transactions will not concurrently modify this record
What are snapshot reads
A normal select... statement is a snapshot read.
Snapshot read makes it possible to repeat the read of an ordinary select... statement at the RR (repeatable read) level. That is, the use of the visible version mentioned in the previous MVCC to ensure data consistency.
What is currently reading
Insert statement, update statement, delete statement, select statement (select... LOCK IN SHARE MODE, select... FOR UPDATE) that show locks are currently read.
Four transaction isolation levels of MySql
1. Four characteristics of transaction (ACID)
The four characteristics of transactions that have to be understood before understanding the transaction isolation level.
1. Atomicity
After the transaction starts, all operations are either done or not done. The transaction is an indivisible whole. When a transaction fails during execution, it will be rolled back to the state before the transaction started to ensure the integrity of the transaction. Similar to the physical explanation of atoms: it refers to the basic particles that cannot be subdivided in chemical reactions, and atoms are indivisible in chemical reactions.
2. Consistency
After the transaction starts and ends, it can ensure the correctness of the database integrity constraints, that is, the integrity of the data. For example, in a classic transfer case, when A transfers money to B, we must ensure that A has deducted the money and B will definitely receive the money. Personal understanding is similar to the conservation of energy in physics.
3. Isolation
Complete isolation between transactions. For example, A transfers money to a bank card to avoid excessive operations at the same time causing the loss of the account amount, so other operations on this card are not allowed until A transfers in.
4. Durability
The impact of the transaction on the data is permanent. The popular explanation is that after the transaction is completed, the operation of the data must be placed (persistent). Once the transaction is completed, it is irreversible. In the operation of the database, once the transaction is completed, it cannot be rolled back.
Second, the issue of transaction concurrency
1. Dirty read
Also called invalid data read. One transaction reads data that has not yet been committed by another transaction is called dirty read.
For example: transaction T1 modifies a row of data, but has not yet committed. At this time, transaction T2 reads the data modified by transaction T1, and then transaction T1 rolls back for some reason, then transaction T2 reads dirty data.
2. Not repeatable
In the same transaction, the same data read multiple times is inconsistent.
For example: transaction T1 reads a certain data, transaction T2 reads and modifies the data, T1 reads the data again in order to verify the read value, and obtains different results.
3. Phantom reading
It is not easy to express the example directly:
In warehouse management, the administrator must enter the warehouse management for a batch of goods that have just arrived. Of course, before entering the warehouse, he must check whether there are previous warehouse records to ensure the correctness. After the administrator A ensures that the product does not exist in the warehouse, the product is put into the warehouse. If at this time, the administrator B will have already put the product into the warehouse because of the hand. At this time, the administrator A finds that the product is already in the library. Just like a phantom reading just happened, something that didn't exist, suddenly he had it.
Note: The three problems seem to be difficult to understand. Dirty reading focuses on the correctness of the data. The non-repeatability focuses on the modification of data, and the phantom reading focuses on the addition and deletion of data.
Three, MySql four transaction isolation levels
problem
Q:
Why are the update, insert, and delete operations all currently read?
A:
Simply put, if the current read is not performed, the integrity constraints of the data may be destroyed. Especially in a high concurrency environment.
Analyze the execution steps of the update statement: update table set… where …;
The InnoDB engine first performs a where query. The result set of the query starts from the first one and performs the current read, then performs the update operation, and then the second data is currently read, and the update operation is performed... So each update is performed with the current read. The same is true for delete, after all, the data must be found before it can be deleted. Insert is a bit different, the unique key check is required before insert operation is executed. One additional sentence: InnoDB engine must have a unique key, and the blog about clustered index will continue to explain it.
The content is organized by referring to online articles, only for personal learning use:
- https://www.cnblogs.com/hello-shf/p/10702316.html#_labelTop
- https://blog.csdn.net/zcl_love_wx/article/details/83305645