MySQL InnoDB MVCC principle

What is MVCC

MVCC (Mutil-Version Concurrency Control) multi-version concurrency control refers to the use of the two isolation levels of committed read ( READ COMMITTD ) and repeatable read ( REPEATABLE READ ) to access records when performing ordinary SEELCT operations The process of version chain , in this way, can make the read-write and write-read operations of different transactions execute concurrently, thereby improving system performance.

A big difference between these two isolation levels is that the timing of generating ReadView is different. Submitted reads will generate a ReadView before each normal SELECT operation, while repeatable reads will only generate one before the first normal SELECT operation. ReadView, the subsequent query operations will reuse this ReadView.

In order to support MVCC, for the DELETE operation, only a delete mark is marked on the record, but it is not actually deleted. After confirming that the ReadView transaction is no longer being accessed, the background thread will be deleted.

Version chain

There are two hidden columns in the row format of the InnoDB storage engine:

1. trx_id: Every time a transaction changes a clustered index record, the transaction id of the transaction is assigned to the trx_id hidden column.
2. roll_pointer: Every time a clustered index record is changed, the old version will be written to 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. Every time a record is changed, an undo log is recorded, and each undo log also has a roll_pointer attribute, which can be connected to form a linked list. This linked list is called a version chain, and the head node of the version chain is the latest value of the current record.

ReadView

ReadView mainly contains 4 more important contents:

1. m_ids: Represents the transaction id list of the read and write transactions that are active in the current system when the ReadView is generated.
2. min_trx_id: Represents the smallest transaction id among the active read and write transactions in the current system when the ReadView is generated, that is, the smallest value in m_ids.
3. max_trx_id: Indicates the id value that should be assigned to the next transaction in the system when the ReadView is generated.
4. creator_trx_id: Represents the transaction id of the transaction that generated the 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:

1. 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 record, so this version can be accessed by the current transaction.
2. If the trx_id attribute value of the accessed version is less than the min_trx_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.
3. If the trx_id attribute value of the accessed version is greater than the max_trx_id value in ReadView, it indicates that the transaction that generated this version will be started after the current transaction generates ReadView, so this version cannot be accessed by the current transaction.
4. If the trx_id attribute value of the accessed version is between the min_trx_id and max_trx_id of ReadView, then you need to determine whether the trx_id attribute value is in the m_ids list. If it is, it means that the transaction that generated this version when the ReadView was created is still active. Cannot be accessed; if not, it means that the transaction that generated the version when the ReadView was created has been committed and the version can be accessed.

If the data of a certain version is not visible to the current transaction, then follow the version chain to find the next version of the data, continue to judge the visibility according to the above steps, and so on, until the last version in the version chain. If the last version is not visible, it means that the record is completely invisible to the transaction, and the query result does not include the record.

Problems encountered in concurrent execution of transactions

1. Dirty write: A transaction modifies data modified by another uncommitted transaction.
2. Dirty read: A transaction reads data modified by another uncommitted transaction.
3. Non-repeatable read: A transaction can only read the data modified by another transaction that has been committed, and after every other transaction modifies and commits the data, the transaction can query the latest value.
4. Phantom reading: A transaction first queries some records based on certain conditions, and then another transaction inserts records that meet these conditions into the table. When the original transaction is queried again according to the conditions, the records inserted by the other transaction can also be inserted. read out.

Four isolation levels

1. Uncommitted reads (READ UNCOMMITTED) can occur dirty reads, non-repeatable reads, and phantom reads
2. Submitted read (READ COMMITTED) can occur non-repeatable reads, phantom reads
3. Repeatable read (REPEATABLE READ) can occur phantom read
4. Serializable (SERIALIZABLE) all kinds of problems can not happen