Multi-version concurrency control in MySQL InnoDB (MVCC)

Disclaimer: This article is a blogger original article, shall not be reproduced without the bloggers allowed. https://blog.csdn.net/GoSaint/article/details/88921244

Brief introduction

MVCC (Multi-Version Concurrency Control) that is multi-version concurrency control.
Most MySQL transactional (such as InnoDB, Falcon, etc.) storage engine to achieve not simple row-level locking. Based on lifting consider concurrent performance, they are generally while achieving MVCC. Not just the current MySQL, another database system (such as Oracle, PostgreSQL) also achieved MVCC. MVCC is worth noting that there is no uniform implementation of standards, so different databases, implement different storage engines are different.

The most widely used as a MySQL storage engine, the article focuses on a multi-version concurrency control InnoDB

MVCC advantages and disadvantages

MVCC in most cases, instead of row locks, the realization of non-blocking read, read not locked, read and write do not conflict. The disadvantage is that each row of records need additional storage space, need to do more line maintenance and inspection work.

The principle of MVCC

undo log

To facilitate understanding of the principles of MVCC, briefly outline the process undo log of work

Using a simplified process in the undo log work without considering the redo log is:

No. action
1 Begin transaction
2 Record data line data snapshot to undo log
3 update data
4 Will undo log to disk
5 The data written to disk
6 Commit the transaction

1) In order to ensure the durability of the data to be submitted before the transaction persistence
2) undo log must be persistent in time before the data persistence, so as to ensure the system crashes, you can use undo log to roll back the transaction

Hidden columns in Innodb

Innodb by undo log to save a snapshot of information has changed the line of the old version.
InnoDB increased internal implementation of the three hidden column for each row of data is implemented MVCC.

Column Name Length (bytes) effect
DB_TRX_ID 6 Transaction identifier for the last transaction inserted or updated row. (Delete considered as an update, it is marked as deleted)
DB_ROLL_PTR 7 Write rollback undo log record (if the row has been updated, the undo log record contains the information needed to reconstruct the line content before updating the line)
DB_ROW_ID 6 Line identification (hide monotonous increment id)

structure

MVCC work process

MVCC only work under READ COMMITED and REPEATABLE READ isolation level two. READ UNCOMMITTED always read the latest data line, rather than in line with the current transaction version of the row. The SERIALIZABLE will read lock on all rows

SELECT

InnoDB Each row will be checked in accordance with two conditions:

  • InnoDB find only version (DB_TRX_ID) earlier than the current transaction version of the row system version number <= System version number of transactions (lines, so you can ensure that the data line either before the beginning has been in existence, either the transaction itself inserted or modified off)
  • Delete line version (DB_ROLL_PTR) or undefined (not updated), or greater than the current transaction version number (updated after the current transaction began). This ensures that the transaction to read a row, has not been deleted before the transaction begins.

INSERT

InnoDB save the current system version number as the row version number for each newly inserted row

DELETE

InnoDB save the current system version number for each row as deleted rows deleted logo

UPDATE

InnoDB to insert a new row record, save the current system version number as the row version number, while preserving the current system version number to delete the original row as the row identifier

Guess you like

Origin blog.csdn.net/GoSaint/article/details/88921244