Multi version concurrency control mvcc of MySQL

Database concurrency control —— lock

Multiversion (version) concurrency control (MCC or MVCC) Multi version concurrency control , It is a common concurrency control of database management system .

We know that lock is commonly used in concurrency control , When a thread wants to operate on a shared resource , Locking is a very simple and crude way ( At the beginning of the business DQL Add read lock , to DML Add write lock ), This kind of lock is a kind of Pessimism How to implement , That is to say, it will block other affairs , This affects database performance .

Let me explain Optimism lock and Pessimistic locking The concept of . I think they are mainly conceptual understanding .

• Pessimistic locking ： When a thread needs to operate on shared resources , First, lock the shared resources , When the thread holds the lock of the resource , When other threads operate on the resource, the Blocking . such as Java Medium Synchronized keyword .
• Optimism lock ： When a thread needs to operate on a shared resource , Don't lock it , It's judgment after the operation .( For example, optimistic locks are controlled by a version number , If the operation is passed after completion Version number Judge whether other threads have operated on the shared resource during the operation of this thread , If so, the notification operation fails , If not, the operation is successful ), Except, of course, Version number also CAS, If you don't know something, you can learn it , It's not too much about .

Database concurrency control ——MVCC

Many people think that MVCC It's a kind of Optimism lock Implementation form , And I think MVCC It's just a optimistic Implementation form , It's through A kind of Visibility algorithm To achieve database concurrency control .

MVCC Two forms of reading

Talking about MVCC The implementation principle before , I think it's necessary to get to know MVCC Two forms of reading .

• Read the snapshot ： Read only the visible version of the current transaction , Don't lock it . And you just have to remember ordinary select Operation is snapshot reading (select * from table where id = xxx).

• The current reading ： Read the current version , such as Special reading operations , to update / Insert / Delete operation

  such as ：

   select * from table where xxx lock in share mode,
   select * from table where xxx for update,
   update table set....
   insert into table (xxx,xxx) values (xxx,xxx)
   delete from table where id = xxx
   Copy code 

MVCC Implementation principle of

MVCC Used “ Three hidden fields ” To achieve version concurrency control , I looked up a lot of information , See a lot of blogs written through A create transaction id Fields and a delete transaction id Field To control the implementation . But it turned out that it wasn't quite right , Let's take a look first MySQL While building the watch innoDB Create the real three hidden columns .

RowID	DB_TRX_ID	DB_ROLL_PTR	id	name	password
Automatically created id	Business id	rollback pointer	id	name	password

• RowID： Hidden self increase ID, When a table is created, no primary key is specified ,InnoDB Will use the RowID Create a clustered index .
• DB_TRX_ID： Recently revised （ to update / Delete / Insert ） The recorded transactions ID.
• DB_ROLL_PTR： rollback pointer , Point to the previous version of this record .

In fact, there is also a deleted flag Field , Used to determine whether the line record has been deleted .

and MVCC It's one of them Transaction fields , Roll back pointer fields , Delete fields . Let's take a look at the table now (isDelete I took it myself , Officially at the beginning of a line content Inside , It doesn't matter where it is , You just need to know that there are ).

isDelete	DB_TRX_ID	DB_ROLL_PTR	id	name	password
true/false	Business id	rollback pointer	id	name	password

So how to achieve through these three fields MVCC Of Visibility algorithm Well ？

Almost something ！ undoLog( Rollback log ) and read-view( Read view ).

• undoLog: Rollback log of transaction , yes Visibility algorithm A very important part of , There are two kinds of .

  • insert undo log： The transaction is generated by inserting a new record undo log, When a transaction is committed, it can be discarded directly
  • update undo log： The business is going on update perhaps delete When it comes to undo log, It's still needed for snapshot reading , So you can't just delete it , Only when the system is not better than this log Earlier read-view You can delete it when it's over .ps： So long transactions generate many old views that lead to undo log Cannot delete A lot of storage space .

• read-view: Read view , yes MySQL Second to create a view , For example, a transaction is in progress select operation ( Read the snapshot ) It will create a read-view , This read-view It's just three fields .

  • alive_trx_list( I took it myself )：read-view Generating time system What is active id.
  • up_limit_id： Record the above alive_trx_list Medium Minimum business id.
  • low_limit_id：read-view Generation time , Current transactions ID The maximum of + 1.

Now , everything , Just the east wind . Let me introduce it , The most important Visibility algorithm .

In fact, the main idea is ： When generated read-view How to get it DB_TRX_ID Go and read-view Three attributes in ( It says ) To make a comparison . Let me talk about three steps , If not very understanding can refer to my later practice combined to understand .

• First of all, compare the DB_TRX_ID Whether it is Less than up_limit_id perhaps Equal to the current transaction id. If meet , It means that the current transaction can see this record . If it is greater than, it will enter the next round of judgment
• Then judge the record DB_TRX_ID whether Greater than or equal to low-limit-id. If it is greater than or equal to, the transaction cannot see the record , Otherwise, we will enter the next round of judgment .
• Judge the record DB_TRX_ID Is it in the array of active transactions , If it is, it means that the record has not been committed and is not visible to the transaction of the current operation , If not, it indicates that it has been submitted , So it's visible .

If the record is not visible to the transaction and ROLL_PTR If it is not empty, it will point to the address of the rollback pointer , adopt undolog To find the visible version of the record .

Now I draw a flow chart of visibility algorithm

 

Actually MVCC It's through " Three " Hide fields ( Business id, rollback pointer , Delete logo ) add undo log And visibility algorithm to achieve version concurrency control .

Reference resources ： Do you really understand MVCC Do you ？ Let's practice it by hand ？ - Nuggets