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