MySQL database multi-version concurrency control MVCC

Table of contents

1. What is Multi-Version Concurrency Control (MVCC)

2. Snapshot read and current read

1. Snapshot read

2. Currently reading

Three, MVCC implementation principle

1. The isolation level applicable to MVCC

2. Implementation principle of hidden fields, undo log version chain

3. ReadView of the realization principle

1. Composition of ReadView

2. The rules of ReadView

3. The process of ReadView

Four. Summary


1. What is Multi-Version Concurrency Control (MVCC)

MVCC (Multiversion Concurrency Control), multi-version concurrency control.
As the name implies, MVCC implements database concurrency control through multiple version management of data rows. This technique enables consistent read operations to be performed under InnoDB's transaction isolation level.

In other words, it is to query some rows that are being updated by another transaction, and you can see their values ​​before they are updated, so that you don't have to wait for another transaction to release the lock when doing the query.

Composition: hidden field (rowId+trxId)+undolog+readview

  • Hidden field (rowId+trxId)
    • rowId: For each row format, there will be a rowid corresponding to a hidden record
    • trxId: A transaction operation will generate a trxid
  • Undo Log: According to the isolation level, to record the data records of each operation, multi-version
  • Read View: According to the corresponding undolog+trxid+isolation level, determine whether a certain record data can be queried

2. Snapshot read and current read

        The implementation of MVCC in MySQL InnoDB is mainly to improve the concurrency performance of the database, and to deal with read-write conflicts in a better way, so that even when there are read-write conflicts, it can also achieve non-blocking concurrent reading without locking, and This read refers to the snapshot read, not the current read.

        The current read is actually a locking operation, which is the implementation of pessimistic locking. The essence of MVCC is a way of adopting optimistic locking ideas.

1. Snapshot read

        Snapshot read, also called consistent read, reads snapshot data. 不加锁All simple SELECTs are snapshot reads , that is, non-blocking reads without locks; for example:

SELECT * FROM player WHERE ...

The reason why snapshot reading occurs is based on the consideration of improving concurrency performance. The implementation of snapshot reading is based on MVCC. In many cases, it avoids locking operations and reduces overhead.

Since it is based on multiple versions, the snapshot read may not necessarily read the latest version of the data, but may be the previous historical version.

The premise of snapshot reading is that the isolation level is not serial level, and snapshot reading at the serial level will degenerate into current reading.

2. Currently reading

        The current read reads the latest version of the record (the latest data, not the historical version of the data). When reading, it must be ensured that other concurrent transactions cannot modify the current record, and the read record will be locked. 加锁的 SELECT, or adding, deleting, and modifying data will be read currently . for example:

SELECT * FROM student LOCK IN SHARE MODE;  # 共享锁

SELECT * FROM student FOR UPDATE; # 排他锁

INSERT INTO student values ...  # 排他锁

DELETE FROM student WHERE ...  # 排他锁

UPDATE student SET ...  # 排他锁

Three, MVCC implementation principle

1. The isolation level applicable to MVCC

insert image description here


2. Implementation principle of hidden fields, undo log version chain

  • Hidden field ( rowId +trxId )

    • rowId: For each row 行格式, there will be a rowid corresponding to a hidden record
    • trxId: One 事务operation will generate a trxid
    • roll_pointer: Every time a clustered index record is modified, the old version will be written into the undo log, and then this hidden column is equivalent to a pointer, through which the information before the modification of the record can be found.
  • Undo Log
    records the data records of each operation according to the isolation level,多版本

        Insert undo only works when the transaction is rolled back. When the transaction is committed, this type of undo log is useless, and the UndoLog Segment it occupies will also be deleted (that is, the Undo 系统回收page linked list occupied by the undo log is either reused or released).


3. ReadView of the realization principle

According to the corresponding corresponding undolog+trxid+隔离级别, 判断决定whether it is possible to query a certain record data

  • Using  READ UNCOMMITTED isolation-level transactions, since records modified by uncommitted transactions can be read, it is good to directly read the latest version of the records.
  • Using  SERIALIZABLE isolation-level transactions, InnoDB stipulates that records are accessed by locking.

1. Composition of ReadView

insert image description here

2. The rules of ReadView

        With this ReadView, when accessing a record, you only need to follow the steps below to determine whether a certain version of the record is visible.

insert image description here

3. The process of ReadView

After understanding these concepts, let's see how the system finds it through MVCC when querying a record:

  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 conforms to the rules.

Four. Summary

        Here is an introduction to the process of MVCC accessing the recorded version chain when transactions at the two isolation levels of READ COMMITTD and REPEATABLE READ execute snapshot read operations. In this way, the read-write and write-read operations of different transactions are executed concurrently, thereby improving system performance.

        The core point is the principle of ReadView. A big difference between the two isolation levels of READ COMMITTD and REPEATABLE READ is the timing of generating ReadView:

  • READ COMMITTD generates a ReadView before every normal SELECT operation
  • REPEATABLE READ only generates a ReadView before the first normal SELECT operation, and then reuse this ReadView for subsequent query operations.

Guess you like

Origin blog.csdn.net/iuu77/article/details/129132863