mysql database | MVCC
This article refers to self-knowledge
MVCC
(Multi-Version Concurrency Control)multi-version concurrency control protocol-MVCC
MySQL InnoDB storage engine, which is based on mvcc
The biggest advantage of MVCC: read without lock, read and write without conflict . In OLTP applications with more reads and less writes, it is very important that reads and writes do not conflict, which greatly increases the concurrent performance of the system. This is why at this stage, almost all RDBMSs support MVCC.
1. MVCC application scenarios
InnoDB engine in MySQL supports MVCC;
应对高并发事务, MVCC 比单纯的加行锁更有效, 开销更小；
MVCC only 读已提交(Read Committed)and 可重复读(Repeatable Read)the isolation level function, and the other two isolation levels incompatible MVCC; (Serializable for isolation level, the data is accessed by locking a mutex, so no MVCC)
MVCC can be implemented based on both optimistic and pessimistic locking.
2. What problems can MVCC solve?
- The problem of blocking between reads and writes: through MVCC, reads and writes can not block each other, reads do not block each other, and writes do not block reads, which can improve data concurrent processing capabilities.
- Reduced the probability of deadlock: This is because MVCC uses an optimistic locking method. When reading data, there is no need to lock, and only need to lock the necessary rows for write operations.
- Solve the problem of consistent read: when we look at a snapshot of a certain database at a point in time, we can only see the result of the transaction submitted and updated before this point in time, and cannot see the update result of the transaction submitted after the point in time.
3. Snapshot read and current read
3.1 Snapshot read
Snapshot read, read the snapshot data, simple Select without lock is a snapshot read.
SELECT * FROM player WHERE ...
3.2 Current reading
Current reading means reading the latest data, not historical data. A locked SELECT, or adding, deleting, or modifying data will perform the current reading.
SELECT * FROM player LOCK IN SHARE MODE;
SELECT FROM player FOR UPDATE;
INSERT INTO player values ...
DELETE FROM player WHERE ...
UPDATE player SET ...
4. MVCC principle
In fact, the principle of MVCC is Read View and undo log
4.1 Transaction version number
Every time a log is opened, a transaction ID (also called a transaction version number ) is obtained from the database . This transaction ID is self-increasing, and the time sequence of the transaction can be judged by the size of the ID.
4.2 Hidden Columns of Row Records
- row_id : hidden row ID, used to generate the default clustered index. If the clustered index is not specified when creating the data table, InnoDB will use this hidden ID to create the clustered index. The use of clustered index can improve the efficiency of data search.
- trx_id : The transaction ID of this data operation, which is the last transaction ID that inserted or updated the data.
- roll_ptr : Rollback pointer, pointing to the Undo Log information of this record.
4.3 Undo Log
InnoDB saves the row record snapshot in Undo Log.
The data rows are connected in series through the structure of the linked list through the snapshot records. Each snapshot saves the trx_id transaction ID. If you want to find the historical snapshot, you can find it by traversing the rollback pointer.
4.4 Read View
If a transaction needs to query row records, which version of row record needs to be read? Read View is to solve this problem. Read View can help us solve visibility problems. Read View saves a list of all active transactions when the current transaction is started . From another perspective, it can be understood as: Read View saves a list of other transaction IDs that should not be seen by this transaction.
Speaking: all ongoing transactions are in Read View
Field:
- trx_ids : The set of transaction IDs currently active in the system.
- low_limit_id : The largest transaction ID of active transactions.
- up_limit_id : The smallest transaction ID among active transactions.
- creator_trx_id : The ID of the transaction that created this ReadView.
If the creator_trx_id of the current transaction wants to read a row record, trx_id of this row record ID, there will be the following situations:
- If
trx_id < 活跃的最小事务ID（up_limit_id）, that is to say, this row record has been committed before the creation of these active transactions, then this row record is visible to the current transaction. - If
trx_id > 活跃的最大事务ID（low_limit_id）this description line record is created after these active transactions, it means that this line record is not visible to the current transaction. - If
up_limit_id < trx_id <low_limit_idit means that the record needs to be in the trx_ids collection, it may still be active, so we need to traverse in the trx_ids collection, if trx_id exists in the trx_ids collection, it proves that the transaction trx_id is still active and invisible, otherwise, trx_id is not Exists in the trx_ids collection, indicating that the transaction trx_id has been submitted, and this row of records is visible.
4.5 The specific process of querying a record?
- Get the version number of the transaction itself, that is, the transaction ID
- Get Read View
- Query the obtained data, and then compare the transaction version numbers in the Read View.
- If it does not meet the ReadView rules, then a historical snapshot in UndoLog is required;
- Finally return data that meets the rules
InnoDB multi-version control (MVCC) through the ReadView+ UndoLogrealization of
preserved historical snapshot UndoLog, ReadView rules to help determine whether the current version of the data is visible.
4.6 Summary
If the transaction isolation level is ReadCommit, each Select of a transaction will check ReadView once, and the Read View of each query is different, which may cause non-repeatable reads or phantom reads.
If the isolation level of the transaction is rereadable, in order to avoid non-rereadable reads, a transaction will only obtain the Read View once in the first Select, and then the Select of the subsequent index will reuse the ReadView.