Analysis & Answer
Multiversion Concurrency Control (MVCC)
InnoDB's MVCC is implemented by saving two hidden columns behind each row of records. These two columns, one saves the creation time of the row, and the other saves the deletion time of the row, not the actual time, but the system version number. The system version number is automatically incremented each time a new transaction is started. The system version number at the beginning of the transaction will be used as the version number of the transaction, which is used to compare with the version number of each row of records queried. MVCC only works under the two isolation levels of rereadable read and committed read.
The operation method of MVCC under repeatable reading
- SELECT
checks each row of records against the following two conditions:- InnoDB only queries data rows whose version is earlier than the current transaction version (that is, the system version number of the row is less than or equal to the system version number of the transaction), which ensures that the rows read by the transaction either exist before the transaction starts, either inserted or modified by the transaction itself);
- The delete version of the row is either undefined or greater than the current transaction version number. This ensures that rows read by a transaction are not deleted prior to the transaction. Only records that meet the above two conditions can be returned as query results.
- INSERT saves the current system version number as the row version number for each newly inserted row.
- DELETE stores the current system version number as the row deletion identifier for each row deleted.
- UPDATE is to insert a new row, save the current system version number as the row version number, and save the current system version number to the original row as the row deletion identifier.
snapshot read
When the select operation is performed, innodb will perform snapshot reading by default, and will record the result of this select, and then return the data of this snapshot when selecting, even if other transactions submit the data that will not affect the current select, this is Implemented repeatable read. The snapshot is generated when the select is executed for the first time, that is to say, assuming that when A starts the transaction and then does not perform any operations, at this time B inserts a piece of data and then commits, and at this time A executes select, then the returned data There will be the piece of data added by B. It doesn't matter whether there are other transaction commits after that, because the snapshot has already been generated, and the subsequent selections are all based on the snapshot.
currently reading
For operations that modify data (update, insert, delete), the current read mode is used. When performing these operations, the latest version number record will be read, and the version number will be changed to the version number of the current transaction after the write operation, so even the data submitted by other transactions can be queried. Suppose you want to update a record, but this data has been deleted and committed in another transaction. If you update, there will be conflicts, so you need to know the latest data when updating. It is precisely because of this that it leads to phantom reading.
- In the case of snapshot reading, MySQL uses mvcc to avoid phantom reading.
- In the current reading situation, MySQL uses next-key to avoid phantom reading
How to solve the problem of phantom reading caused by current reading
Use serializable isolation level
SERIALIZABLE will lock every row of data read, so it may cause a lot of timeout and lock competition problems. This isolation level is rarely used in practical applications. It is considered to be used only when it is very necessary to ensure data consistency and no concurrency is acceptable.
Use next-key lock
A next-key lock is a section of an index row that opens before closing and then closes. It is the basic unit of MySQL locking. Next-key locks are also a combination of row locks and gap locks.
- Row lock The lock of a single row record, the primary key and the unique index are the lock modes of the row record, to avoid phantom reading of the current transaction when other transactions perform update operations;
- Gap lock A gap lock is an open interval on an index row. The gap lock is implemented based on a non-unique index. Since the indexes in InnoDB are ordered, when the current transaction updates data based on a non-unique index, InnoDB will add a gap lock to the non-unique index. , to block the data rows that need to be inserted by other transactions, so as to avoid phantom reading of the current transaction when other transactions perform insert operations;
Reflect & Expand
Meow Interview Assistant: One-stop solution to interview questions, you can search the WeChat applet [Meow Interview Assistant] or follow [Meow Brush Questions] -> Interview Assistant free questions. If you have good interview knowledge or skills, look forward to your sharing!