Deeply understand mvcc and bufferpool caching mechanism

MVCC Multi version concurrency control mechanism
Mysql How to ensure high transaction isolation at the repeatable read isolation level , We showed you last class , alike sql Query statements in a transaction The query results are the same when executed multiple times in , Even if other transactions modify the data, it will not affect the current transaction sql Query result of statement . This isolation depends on MVCC(Multi-Version Concurrency Control) Mechanism to guarantee , Read and write operations on a row of data default to It will not ensure isolation by locking mutual exclusion , Avoid frequent locking and mutual exclusion , In the serialization isolation level, in order to ensure high isolation, all operations are separated It is realized by locking and mutual exclusion . Mysql At the read committed and repeatable read isolation levels MVCC Mechanism .
undo Log version chain and read view Detailed explanation of mechanism
undo Log version chain refers to that a line of data is modified by multiple transactions in turn , After each transaction is modified ,Mysql The data before modification will be retained undo Roll back journal , And with two hidden fields trx_id and roll_pointer Put these undo Logs are concatenated to form a chain of historical versions ( See the picture below , Visual reference required Understand the examples in the frequency )

stay Repeatable read isolation level , When the transaction opens , Execute any query sql Will generate the current transaction Consistency view read-view, This view is displayed at the end of the transaction It hasn't changed before **( If it is read, the isolation level has been committed at each query execution sql Time will regenerate )**, This view consists of all uncommitted things when executing the query service id Array （ The smallest in the array id by min_id） And the largest transaction that has been created id（max_id） form , Anything in business sql The query results need to be from the corresponding Start with the latest version in the data chain read-view Do a comparison to get the final snapshot result .
Version chain alignment rules ：

1. If row Of trx_id It falls on the green part ( trx_id<min_id ), Indicates that this version was generated by a committed transaction , This data is visible ;
2. If row Of trx_id It falls on the red part ( trx_id>max_id ), Indicates that this version is generated by a transaction that will be started in the future , It's invisible ( if row Of trx_id It's that your own affairs are visible at present ）;
3. If row Of trx_id It falls on the yellow part (min_id <=trx_id<= max_id), There are two situations
   a. if row Of trx_id In the view array , Indicates that this version is generated by uncommitted transactions , invisible ( if row Of trx_id Is the current self Your own affairs are visible );
   b. if row Of trx_id Not in the view array , Indicates that this version is generated by committed transactions , so .
   In the case of deletion, it can be regarded as update In special circumstances , The latest data in the version chain will be copied , And then trx_id Modify to delete trx_id, At the same time, in the header information of the record （record header） Inside （deleted_flag） Mark bit write true, To indicate that the current record has been Delete , When querying, the corresponding records are found according to the above rules delete_flag The tag bit is true, It means that the record has been deleted , The number... Is not returned According to the .

Be careful ：begin/start transaction Command is not the starting point of a transaction , The first modification after executing them InnoDB Statement of table , The business really starts , To mysql Application affairs id,mysql Internally, transactions are allocated strictly according to the order in which they are started id Of .

summary ： MVCC The mechanism is realized by read-view Mechanism and undo Version chain comparison mechanism , This enables different transactions to be read according to the data version chain comparison rules Different versions of the same data in the version chain .

Innodb engine SQL Executive BufferPool Caching mechanisms

Why? Mysql You can't directly update the data on the disk, and set up such a complex mechanism to execute SQL 了 ？

Because a request directly reads and writes the disk file randomly , Then update the data in the disk file. The performance may be quite poor .
Because the performance of disk random read and write is very poor , Therefore, directly updating disk files cannot make the database resist high concurrency . Mysql This mechanism looks complex , But it can ensure that every update request is to update memory BufferPool, Then write log files sequentially , And at the same time Ensure data consistency under various abnormal conditions . The performance of updating memory is very high , Then the performance of writing log files on disk sequentially is also very high , Much higher than random reading and writing disk files . It is through this mechanism , To make our MySQL The database can resist several dry read and write requests per second on a highly configured machine .