MySQL's High Concurrency Processing Technology MVCC

Get technical dry goods and industry information for the first time!

MySQL's High Concurrency Processing Technology MVCC

In the recent May Day holiday, in addition to taking the kids around, I also read a few pages of "High-Performance MySQL". In addition, there is a "Highly Available MySQL" at home, which are all the books that I gave when I was writing in CSDN. There are more than 40 books before and after, and some of them were thrown away before moving, which is a pity. . .

We all know that there are a lot of locks in MySQL. For example: shared locks, exclusive locks; table locks, row locks; read locks, write locks, etc. These locks tend to reduce the concurrent processing capability of the MySQL system when processing data. In the earliest database system, only reads and reads can be concurrent, and reads and writes, writes and reads, and writes and writes are all blocked. After the introduction of multiple versions, only writes and writes block each other, and the other three operations can be parallelized, which greatly improves the concurrency of InnoDB. Multi-version processing technology is the MVCC we are talking about today.

MVCC simply means that in InnoDB, two additional hidden values ​​are added after each row of data to realize MVCC. One of these two values ​​records when this row of data is created, and the other records when this row of data is created. Expired (or deleted).
In actual operation, what is stored is not the time, but the version number of the transaction. Each time a new transaction is opened, the version number of the transaction is incremented. Each row of data adds a version identifier. In a version solution based on a database table, this is generally achieved by adding a "version" field to the database table. When reading out the data, read this version number together, and add one to this version number when updating later. At this point, the version data of the submitted data is compared with the current version information of the corresponding record in the database table. If the version number of the submitted data is greater than the current version number of the database table, it will be updated, otherwise it is considered to be out of date data.

MySQL's High Concurrency Processing Technology MVCC
Seeing this, I believe many people will think of CAS operation. Isn't this MVCC similar to CAS operation? In fact, many things in the programming world are similar. If you read "UNIX Network Programming", you will find that the concurrent programming model in Java actually refers to some concurrent programming models in the bottom layer of the operating system.

From Dao Zhi Jian, I remembered that I wrote these words in an earlier article. The multi-version processing logic of MVCC under the MySQL default transaction isolation level is as follows:

  • In SELECT, read creation version number <= current transaction version number, delete version number is empty or> current transaction version number.

  • When INSERT, save the current transaction version number as the creation version number of the row

  • When DELETE, save the current transaction version number as the delete version number of the row

  • During UPDATE, insert a new record, save the current transaction version number as the row creation version number, and save the current transaction version number to the originally deleted row

Through MVCC, although each row of records requires additional storage space, more row inspection work and some additional maintenance work, it can reduce the use of locks. Most read operations do not need to lock, and the data read operation is very simple and performance Very good, and it can also guarantee that only the rows that meet the standard will be read, and only the necessary rows will be locked.

In general, MVCC has the following characteristics:

  • There is a version for each row of data, and the version is updated every time the data is updated

  • Copy the current version when modifying, and then modify at will, no interference between various transactions

  • Compare the version number when saving, if it succeeds (commit), the original record will be overwritten, and if it fails, the copy (rollback) will be abandoned.

  • That is, each line has a version number. When saving, it is determined whether it is successful or not according to the version number. It sounds like an optimistic lock, because this seems to be the case. You can know whether the submission is successful at the time of submission.

Guess you like

Origin blog.51cto.com/15127565/2666204