Mysql's query efficiency is so high, it turned out to be like this (MVCC is super simple to understand)

MVCC multi-version concurrency control mechanism

The same sql query statement is executed multiple times in a transaction and the query result is the same. Even if other transactions modify the data, it will not affect the query result of the current transaction sql statement. How do these Mysql do it?

How does Mysql guarantee high transaction isolation under the repeatable read isolation level (default level)?

The isolation of Mysql is guaranteed by the MVCC (Multi-Version Concurrency Control) mechanism. By default, the read and write operations of a row of data will not ensure isolation by locking and mutual exclusion, avoiding frequent locking and mutual exclusion. , And in order to ensure higher isolation in the serialized isolation level, all operations are locked and mutually exclusive . Mysql implements the MVCC mechanism under both read submitted and repeatable read isolation levels.

Detailed explanation of undo log version chain and read view mechanism

The undo log version chain means that after a row of data has been 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 (transaction id) and roll_pointer( Rolling pointer) connect these undo logs in series to form a historical record version chain.

Insert picture description here
Under the repeatable read isolation level, when the transaction is turned on, the only view read-view of the current transaction will be generated when any query sql is executed , and the view will not change before the end of the transaction (if it is read committed isolation level in each execution It will be regenerated when querying sql), this view is composed of all uncommitted transaction id arrays (the smallest id in the array is min_id) and the largest transaction id (max_id) created when the query is executed . Any SQL query results in the transaction need to be obtained from The latest data in the corresponding version chain is compared with read-view one by one to get the final result. Version chain comparison rules:

  1. If the trx_id of row falls in the green part (trx_id<min_id ), it means that this version is generated by the 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 the transaction started in the future and is invisible (if
    the trx_id of the row is the current own transaction is visible);
  3. If the trx_id of row falls in the yellow part (min_id <=trx_id<= max_id), there are two cases
  • 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 own transaction is visible);
  • If the trx_id of row is not in the view array, it means that this version is generated by the transaction that has been submitted and is visible.

For the case of deletion, it can be considered as a special case of update. The latest data on the version chain will be copied, and trx_id will be modified to the
trx_id of the delete operation . At the same time, the (deleted_flag) in the record header of the record ) Write true in the flag bit to indicate that the current record has been
deleted. When querying the corresponding record according to the above rules, if the delete_flag flag bit is true, it means that the record has been deleted, and no data is returned
.

Note : The begin/start transaction command is not the starting point of a transaction. After executing the first statement to modify the InnoDB table after they are executed, the transaction is really started, and then the transaction id will be applied to mysql. The internal mysql strictly follows the transaction. Start order to allocate transaction id.

Summary:
The realization of the MVCC mechanism is through 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.

Guess you like

Origin blog.csdn.net/weixin_51049616/article/details/108789681