MySQL Optimization Lesson 7: In-depth understanding of MVCC and BufferPool caching mechanism

MVCC multi-version concurrency control mechanism

How Mysql ensures high transaction isolation under the repeatable read isolation level, as demonstrated in the last lesson, the same SQL query statement is executed multiple times in a transaction with the same query result, even if other transactions modify the data, it will not affect the data The query result of the current transaction sql statement.

This isolation is guaranteed by the MVCC (Multi-Version Concurrency Control) mechanism. By default, the two operations of reading and writing a row of data will not ensure isolation by locking mutual exclusion, avoiding frequent locking and mutual exclusion. In the serialization isolation level, in order to ensure higher isolation, it is achieved by locking all operations with mutual exclusion.

Mysql inread committedandrepeatable readThe MVCC mechanism is implemented under the isolation level.

Detailed explanation of undo log version chain and read view mechanism

The undo log version chain means that after a row of data is modified by multiple transactions in turn, after each transaction is modified, Mysql will retain the undo rollback log of the data before the modification, and use two hidden fields trx_id and roll_pointer to concatenate these undo logs form a chain of historical versions

The uncommitted transaction id contained in "uncommitted and committed transaction" must be greater than or equal to 200,
and the committed transaction id contained in "uncommitted and committed transaction" may be less than 200

In 可重复读隔离级别, when the transaction is opened, the current transaction will be generated when any query sql is executed 一致性视图read-view, and the view will not change until the end of the transaction ( 如果是读已提交隔离级别在每次执行查询sql时都会重新生成), this view consists of an array of all uncommitted transaction ids when the query is executed (the smallest id in the array is min_id ) and the created maximum transaction id (max_id). Any SQL query result in the transaction needs to be compared with the read-view one by one from the latest data in the corresponding version chain to obtain the final snapshot result.

Version chain comparison rules:

1. If the trx_id of the row falls in the green part ( trx_id<min_id ), it means that this version is generated by a committed transaction, and this data is visible;

2. If the trx_id of the row falls in the red part ( trx_id>max_id ), it means that this version is generated by a transaction started in the future and is definitely invisible

3. If the trx_id of the row falls in the yellow part (min_id <=trx_id<= max_id), it includes two cases:
   a. If the trx_id of the row is in the view array, it means that this version is generated by a transaction that has not yet been committed and is not visible , if the trx_id of the row is the current transaction id, it is visible
   b. If the trx_id of the row is not in the view array, it means that this version is generated by the committed transaction and is visible.

For deletion, it can be considered as a special case of update. The latest data on the version chain will be copied, and then the trx_id will be changed to the trx_id of the delete operation. ) flag bit is written with true to indicate that the current record has been deleted. When querying, the corresponding record is found according to the above rules. If the delete_flag flag bit is true, which means that the record has been deleted, no data will be returned.

Note:
The begin/start transaction command is not the starting point of a transaction. After the first statement that modifies the operation of the InnoDB table is executed, the transaction is actually started, and the transaction id is applied to mysql. The internal mysql strictly follows the transaction. Startup sequence to assign transaction id's.

Summary:
The implementation of the MVCC mechanism is to use the read-view mechanism and the undo version chain comparison mechanism, so that different transactions will read different versions of the same data on the version chain according to the data version chain comparison rules.

BufferPool caching mechanism for Innodb engine SQL execution

Why can't Mysql directly update the data on the disk and set up such a complex mechanism to execute SQL?
Because a request directly reads and writes to the disk file randomly, and then updates the data in the disk file, the performance may be quite poor.
Because the performance of random read and write on disk is very poor, directly updating disk files cannot make the database withstand high concurrency.
This mechanism of MySQL looks complicated, but it can ensure that each update request is 更新内存BufferPool, and then 顺序写日志文件(much faster than random writes), while also ensuring data consistency in various abnormal situations.
The performance of updating memory is extremely high, and the performance of sequentially writing log files on disk is also very high, much higher than reading and writing disk files randomly.
It is through this mechanism that our MySQL database can resist several dry read and write requests per second on machines with higher configuration.