MVCC: Multiversion Concurrency Control

1. What is MVCC

• MVCC (Multi Version Concurrency Control), multi-version concurrency control;
• MVCC is used to solve the problem of read-write concurrency and avoid problems such as dirty reads and phantom reads;
• MVCC implements concurrency control through multiple version management of data rows;
• MVCC guarantees consistent read operations under the transaction isolation level of InnoDB, that is, when querying some data being modified by other transactions, it does not need to wait, but directly reads the value before the data is updated;
• Different databases may implement MVCC in different ways, and only the InnoDB engine supports MVCC in the MySQL database;
• The implementation of MVCC depends on: 1) Hidden fields of row records; 2) Undo Log; 3) Read View;
• MVCC only works for two isolation levels: read committed and repeatable read;

2. Snapshot read and current read

• In the read-write conflict problem solved by MVCC lock, read refers to snapshot read;

2.1 Snapshot read

• Snapshot read is consistent read, which reads the snapshot data instead of the current latest data;
• A SELECT that does not explicitly lock is a snapshot read;
• Snapshot reading can enable concurrent reading without locking even if there is a read-write conflict, improving concurrent performance;
• Snapshot reading is based on multi-version management control, and sometimes what is read is not necessarily the latest data, but may be the previous historical version;
• The premise of snapshot reading is that the transaction isolation level is not serialized, otherwise snapshot reading degenerates into current reading;

2.2 Current reading

• The current read refers to reading the latest data. When reading, it is necessary to ensure that other transactions cannot modify the data, so the data needs to be locked;
• Explicitly locked SELECT or adding, deleting, and modifying data will execute the current read;
  

3. Read View

• MVCC manages the visibility of records in Undo Log through Read View, and determines the corresponding version of the record that needs to be read by the current transaction;
• The record contains three hidden fields: 1) row_id: used to build a clustered index in special cases; 2) trx_id: transaction id, indicating the latest transaction ID for updating the record; 3) roll_pointer: rollback pointer, used Roll back the record to the specified historical version;
• The historical version of the record is constructed through Undo Log, and the modification of the same record by multiple transactions will be saved in the form of Undo Log, and these logs will exist in the form of a linked list (connected by the rollback pointer in the record), such as:
  
• When the transaction is started, a snapshot will be generated for the current database system. The snapshot is the Read View, which is maintained as follows: 1) The transaction ID of the Read View is generated; 2) The active transaction ID in the system when the current Read View is generated; etc. information;
• The main function of Read View is to confirm which versions are visible to the current transaction in the record corresponding version chain;
• Note that MVCC is used to resolve read-write conflicts, and only corresponds to two isolation levels: Read Committed and Repeatable Read. Therefore, the specific generation of Read View is related to the isolation level: 1) When the isolation level is Read Committed, dirty reads can be
  resolved problem, so the corresponding Read View will be generated for each SELECT query;
  2) When the isolation level is repeatable read, it can solve the problems of dirty read, non-repeatable read and phantom read, so for multiple SELECT queries in a transaction The corresponding Read View will only be generated for the first time;

3.1 What is included in Read View

• creator_trx_id : Create the transaction ID of this Read View (the transaction id will be assigned to the transaction only when the records in the table are changed (when executing INSERT, DELETE, UPDATE statements), otherwise the transaction id value in a read-only transaction Both default to 0);
• trx_ids : Indicates the transaction id list of active read and write transactions in the current system when ReadView is 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 ReadView is generated, and low_limit_id is the largest transaction id value
  in the system ;

3.2 Rules of ReadView

When accessing a record, through ReadView, you only need to follow the steps below to determine whether a certain version of the record is visible:

• If the trx_id attribute value of the accessed version is the same as the creator_trx_id value in ReadView , it means that the current transaction is accessing its own modified records, so this version can be accessed by the current transaction;
• If the trx_id attribute value of the accessed version is smaller than the up_limit_id value in ReadView , it indicates that the transaction that generated this version has been committed before the current transaction generates ReadView, so this version can be accessed by the current transaction;
• If the trx_id attribute value of the accessed version is greater than or equal to the low_limit_id value in ReadView , it indicates that the transaction that generates this version is opened after the current transaction generates ReadView, so this version cannot be accessed by the current transaction;
• If the trx_id attribute value of the accessed version is between the up_limit_id and low_limit_id of ReadView , then you need to judge whether the trx_id attribute value is in the trx_ids list : 1) If it is, it means that the transaction generating this version is still active when creating ReadView, This version cannot be accessed; 2) If not, it means that the transaction that generated this version has been submitted when ReadView was created, and this version can be accessed;
  
  

4. The overall operation process of MVCC

When querying a record, the system uses MVCC to read it according to the following steps:

1. First obtain the version number of the transaction itself, that is, the transaction ID;
2. getReadView;
3. Query the obtained data, and then compare it with the transaction version number in ReadView;
4. If the ReadView rule is not met, a historical snapshot needs to be obtained from the Undo Log;
5. Finally, return the data that meets the rules. If no version that meets the rules is found, it means that the record does not exist;

Refer to "Silicon Valley: Master Kong"