MySQL - MVCC in plain English

To summarize in one sentence:   MVCC uses a non-blocking method to solve Mysql InnoDB read and write concurrency conflicts, and achieves the transaction isolation levels of Mysql Read Committed (RC) and Repeatable Read (RR).

      

The main method of implementation is: through undolog version chain + Read View.

1. What is MVCC

MVCC(multi-version-concurrent-control) 

 MVCC stands for multi-version concurrency control. MVCC is a concurrency control method that is generally used in database management systems to achieve concurrent access to the database and to implement transactional memory in programming languages.

2. The role of MVCC

        The implementation of MVCC in MySQL InnoDB is mainly to improve the concurrency performance of the database and use a better way to handle read-write conflicts to achieve == no locking and non-blocking concurrency even when there are read-write conflicts. Read ==.  

        For databases, when it comes to concurrency, it involves things. MVCC mainly solves the read committed (RC, non-repeatable read) and repeatable read (RR) problems of transactions in non-blocking situations .


MVCC accesses concurrent transactions based on "data version".

Thinking: How to solve the transaction isolation level, read uncommitted and serialization?


3. Principle of MVCC

MVCC的目的就是多版本的并发控制,在数据库中的实现,就是为了解决读-写冲突的问题,
它的实现原理主要是依赖记录中的 3个隐式字段、undo日志、read view 来实现的。

 InnoDB adds three hidden fields to each row of data, a unique row number, a record creation version number, and a record rollback version number.

                                        Figure 1  

 DB_ROW_ID:
6byte, implicit auto-increment ID (hidden primary key). If the data table does not have a primary key, InnoDB will automatically generate a clustered index with DB_ROW_ID.
DB_TRX_ID:
6 bytes, the most recently modified (modified, inserted) transaction ID: records the ID of the transaction that created this record and last modified the record. It is a pointer.
DB_ROLL_PTR:
7byte, rollback pointer, pointing to the previous version of this record (the previous version is stored in the rollback segment).
DELETED_BIT:
1 byte. Being updated or deleted does not mean that the record is actually deleted, but that the deletion flag has changed, which is equivalent to a logical deletion of the record.

3.1 Version chain

         In multi-version concurrency control, in order to ensure data operations in the multi-thread process, a transaction isolation mechanism is ensured, reducing the pressure of lock competition and ensuring a higher amount of concurrency. Every time a transaction is started, a transaction version number will be generated, and the operated data will generate a new data row (temporary), but it will not be visible to other transactions before submission. For data updates (including additions, deletions, and modifications) ) If the operation is successful, the version number will be updated to the data row. If the transaction is submitted successfully, the new version number will be updated to the data row. This ensures that the data of each transaction operation does not affect each other, and also There is no lock problem.

Figure II

3.2 undo-log

        Undo log is used for rollback. The specific content is to copy the database content (rows) before the transaction to the undo buffer, and refresh the content in the undo buffer to the disk at the appropriate time. The undo buffer, like the redo buffer, is also a ring buffer, but when the buffer is full, the contents of the undo buffer will also be flushed to the disk; unlike the redo log, there is no separate undo log file on the disk, all The undo logs are all stored in the main ibd data file (table space), even if the client sets one data file per table.

3.3 Read View Snapshot

Transaction snapshots are used to store the transaction running status of the database.
The creation process of a transaction snapshot can be summarized as:

        1. View all currently uncommitted and active transactions, stored in the array ( trx_ids)
        2. Select the smallest XID among the uncommitted and active transactions, and record it in xmin of the snapshot ( limit_trx_id)
        3. Select all submitted transactions The largest XID in , plus 1, is recorded in xmax ( max_trx_id )

Read View (mainly used for visibility judgment) : When creating a new transaction, copy a list of active transactions in the current system. Meaning, a list of other transaction IDs that should not be seen by this transaction currently.

        The generation timing of the Read View snapshot is also very critical. It is precisely because of the difference in generation timing that the two isolation levels of RC and RR have different visibility;

        In innodb (default repeatable read level), a transaction will create a snapshot (Read View) after the first select read operation after begin/start transaction, and record other active transactions in the current system in innodb
( read committed level), each select statement in the transaction will create a snapshot (Read View)

 RC is statement-level multi-version (multiple read-only statements of a transaction, creating different ReadViews, which is more expensive), RR is transaction-level multi-version (one ReadView); snapshot read: it is the most common select query SQL
        statement.

        For example, the select operation without locking is snapshot reading, that is, non-blocking reading without locking; the premise of snapshot reading is that the isolation level is not the serial level, and the snapshot reading at the serial level will degenerate into the current reading; the reason why snapshot reading occurs The situation is based on the consideration of improving concurrency performance. The implementation of snapshot reading is based on multi-version concurrency control, that is, MVCC. It can be considered that MVCC is a variant of row lock, but in many cases, it avoids locking operations and reduces the cost. 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.


        Current reading: refers to the way to read data when the following statements are to be executed.

                        Insert /update / Delete
                        Select... for update
                        Select... lock in share mode

                Operations such as select lock in share mode (shared lock), select for update; update, insert, delete (exclusive lock) are all current reads. Why is it called current read? That is, it reads the latest version of the record. When reading, it must also ensure that other concurrent transactions cannot modify the current record, and the read record will be locked.

ReadView data structure:


 

3.4 Rules for reading transaction data in memory snapshots

 

read committed 总是读最新一份快照数据,而repeatable read 读事务开始时的行数据版本。
 
read Commited隔离级别判断算法在每次语句执行的过程中,都关闭read_view, 
重新创建当前的一份新的read_view。
 
read view中事务id  min_trx_id~max_trx_id,当前事务T1。
...执行sql,创建一份最新的read_view;
...T1<min_trx_id,说明T1事务比较早,该行对当前事务T1可见。
...T1 > max_trx_id,说明T1比较晚,该行对当前事务不可见,根据DB_ROLL_PTR找到上一个判断再次判断。
...min_trx_id <= T1 <= max_trx_id,如果read_view中有该事务,则不可见,找上一个版本。
如果不在则可见(在read commited下)。
 
repeatable read各级离别下判断算法:创建事务trx结构的时候,就生成了当前的global read view。
...trx_id_1< min_trx_id那么表明该行记录所在的事务已经在本次新事务创建之前就提交了,
所以该行记录的当前值是可见的。
...trx_id_1>max_trx_id的话,那么表明该行记录所在的事务在本次新事务创建之后才开启,
所以该行记录的当前值不可见。通过DB_ROLL_PTR找到上一版数据判断
...min_trx_id<=trx_id_1<=max_trx_id,
 那么表明该行记录所在事务在本次新事务创建的时候处于活动状态,
从min_trx_id到trx_id_max进行遍历,
如果trx_id_1等于他们之中的某个事务id的话,那么不可见。
通过DB_ROLL_PTR找到上一版数据判断`


4. Case analysis

The case comes from (IT Lao Qi) 
 

Figure 3 shows the status between the four transactions A, B, C, and D.
Figure 4 shows the version chain corresponding to the four transactions A, B, C, and D.


           Figure 3 transaction status

Figure 4 Undolog version chain corresponding to the transaction
 

        Why is the first data in the undo_log version chain because it is original data without transaction trx_id and previous version pointer.
Will undo_log not be deleted? If the intermediate data is deleted, won't the version chain be broken?
Answer: The undo_log version chain is not deleted immediately. Mysql will ensure that the version chain data is no longer referenced before deleting it.

4.1 Case analysis in the case of RC
 

 Under the repeatable read isolation level, Figure 5 shows the time sequence of the two queries of transaction D, and the status of the Read View at that time.

Figure 6 analyzes the status of Read View when transaction D is first queried, and analyzes the results. Figure 7 analyzes the status of Read View when transaction D is first queried, and analyzes the results.

Figure 5: Case analysis of repeated reading under the RC transaction isolation sector  

 Figure 6: Under the RC transaction isolation sector, the first select query data rule of transaction D

        For the first selection of transaction D, the currently uncommitted transactions include m_ids(2,3,4). We analyze which transaction's data is readable according to the access rules of the version chain. (Note: Under the RC isolation level, each transaction will obtain a new Read View). We apply the rules from back to front based on the rollback pointer. When trx_id=3, min_trx_id(2)<3<= max_trx_id(5) exists in m_ids(2,3,4) and cannot be accessed. Then go back to the previous version trx_id = 2 and cannot be accessed at this time. Continue Backtracking, when trx_id = 1, 1< min_trx_id(2), can be accessed, then the first select will obtain the value of the data of transaction trx_id =1 in the version chain.

Figure 7: Under the RC transaction isolation level, the rules for querying data in the second select of transaction D

 Similarly for the second select, trx_id = 2 allows us to access the data. For the same transaction D, we repeatedly query, but we get different results, making it impossible to read repeatedly.

Figure 8: Under the RR transaction isolation level, the first and second select query rules of transaction D

 For Repeatable Read (Repeatable Read) isolation level, transaction D accesses the same ReadView during the entire process, so the data they obtain twice is consistent. This solves the problem of non-repeatable reads. But phantom reading still occurs.

5. Let’s summarize MVCC:

 MVCC uses a non-blocking method to resolve Mysql InnoDB read and write concurrency conflicts, and implements the transaction isolation levels of Mysql Read Committed (RC) and Repeatable Read (RR).

The main method of implementation is: through undolog version chain + Read View.

Guess you like

Origin blog.csdn.net/u010445301/article/details/126090740