Fundamental
MVCC is achieved by storing data in the snapshot at a point in time to achieve. This means that a transaction no matter how long run, in the same transaction can be seen in the consistent view of data. Depending on the time the transaction began, but also means that different transactions at the same time see the same table data may be different.
Basic Features
- Each row of data there is a version, the version is updated each time the data is updated.
- Copy the current version freely modified when modifications, no interference between the various transactions.
- Save when comparing the version number, if successful (commit), then overwrite the original recording; failure to give up the copy (rollback)
InnoDB storage engine MVCC implementation strategies
Save two extra hidden column in each row of data: the version number and version number of the current row deleted creation. Here's the version number is not the actual time value, but the system version number. Each new transaction begins, the system will automatically increment the version number. System version number will be the start time of the transaction as the version number of the transaction, for each query and version number of rows to compare.
Each transaction has its own version number, in such a transaction is executed CRUD operations, it is by comparing the version number to achieve the purpose of data version control.
Let's take a look at is how to achieve specific.
Version chain
We first understand what the concept version of the chain. In the InnoDB table engine, its clustered index record the necessary two hidden columns:
When the transaction id on each article of a clustered index record id is used to modify the stored trx_id.
roll_pointer each time which of the clustered index recorded modify the time, the old version will be written to undo log. This saved roll_pointer is a pointer to this clustered index on a recorded version of the location, to obtain a version of the information recorded on it by. (Note that the insert operation undo logs do not have this property, because it does not have the old version)
For example, now there is a transaction id is to modify the sentence of execution of this record 60
In this case there chain version undo log
ReadView
Said a version of the chain we look at ReadView. Read Committed Repeatable Read and difference is that they generate ReadView different strategy.
For example, in the case has been submitted to Read isolation level:
At this time, a transaction such as a transaction id 100, modify the name, so that the name is equal to 2 Xiaoming, but not submitted to the transaction. In this case the version chain is
At this point another transaction that initiated the select statement to query id record 1, that generated at this time ReadView list only [100]. Then go look for the chain version, first be sure to find the nearest one, I found trx_id is 100, which is the name to Bob that record 2, found in the list, it can not be accessed.
By this time we continue to find the next pointer, name to a recording Xiaoming found trx_id 60 is less than the minimum id list, can be accessed, the access result directly to Bob 1.
Well, this time we submitted the transaction id for the transaction 100 and a transaction id for the new 110 also modify the record id 1, and do not commit the transaction
This is the time to release chain
Before this time the select transaction and execute a query to query for the record id 1.
If you are already read committed isolation level, this time you will regenerate a ReadView, that the value of your activity list affairs had changed into a [110].
According to the statement, you go through trx_id contrast version chain to find a suitable result is Bob 2.
If you are repeatable read isolation level, this time your ReadView the first time select when generated ReadView, which is a list of values or [100]. So the result is that select Xiao Ming 1. So select the second result and for the first time, as it is called repeatable read!
That has actually commit Read isolation level to generate a separate ReadView at the beginning of each query will be, and repeatable read isolation level is generated in a ReadView first read, after reading all the previous multiplexed readView.
Mysql in the summary of MVCC
Objectively, we believe that he is optimistic locking implementation of a whole, that is, each line has a version number, when deciding whether to save success according to the version number. However, due to Mysql write operation will add exclusive lock (previously there speaking), if the lock still be considered MVCC? Understand optimistic locking little friends, we know that rely mainly on version control, namely the elimination of the lock, the two contradict each other, so in a sense, Mysql's MVCC MVCC is not really, he just borrowed the name implements MVCC non-blocking read it.