MySQL-Multiversion Concurrency Control

I. Concept

mvcc implements database concurrency control through multiple version management of data rows.This technology ensures that consistent read operations are performed under the transaction isolation level of innoDB.It is to query some rows that are being updated by another transaction, and you can see the values ​​before they are updated, so that you do not have to wait for another transaction to release the lock when doing the query.

Second, snapshot read and current read

mvcc is implemented in MySQL InnoDB mainly to improve the concurrent performance of the database, to better handle read-write conflicts, so that even if there are read-write conflicts, no locks can be added, and non-blocking concurrencyRead, this read refers to snapshot read, not current read.The current read is actually a locking operation, the realization of pessimistic locking, and the essence of mvcc is the realization of optimistic locking.

1. Snapshot read (consistent read)

Reads are snapshot data. Simple selects without locks belong to snapshot reads. They may not be the latest data, but may be historical versions. The premise is that the isolation level is not serial.A snapshot read at the row level may degenerate into a current read.

2. Current reading

The current version is read. When reading, it needs to be locked to ensure that the data under a certain transaction will not be modified by other transactions.

Third, MVCC implementation principle of ReadView

1. What is ReadView

Transactions are used to query the historical snapshots stored in the undo log and provide row visibility. Innodb constructs an array for each transaction to record and maintain the ID of the current active transaction in the system (started but stillnot submitted)

2. Design ideas

• Using READ UNCOMMITED isolation level transactions, you can read uncommitted transactions, so MVCC is not used, so the latest data is read without reading historical data;
• Use the SERIALIZABLE isolation level transaction, innodb stipulates the use of locking to access records;
• Transactions using the READ COMMITTED and REPEATABLE READ isolation levels must ensure that the records modified by the committed transaction are read.Adding another transaction has modified the record but has not yet submitted it, so the latest version of the record cannot be directly read. The core problem is to determine which version in the version chain is visible to the current transaction. This is the main problem to be solved by ReadView.
• cread_trx_id: The transaction id that created this read view;
• trx_ids: A list of transaction ids representing the active read and write transactions in the current system when the read view was generated;
• up_limit_id: The smallest transaction id in active transactions;
• low_limit_id: Indicates the id value that should be assigned to the next transaction in the system when the read view is generated.Is the system's largest transaction id.