Step 4 What are the principles of MVCC MVCC, transactional ACID, things isolation level, Innodb storage engine is how to achieve the MVCC

MVCC is to deal with concurrency issues, improve the efficiency of concurrent access, read without blocking write.
Things
A atom of the
C Consistency
I Isolation
D persistent
problem of high concurrent scenes
dirty reads
unrepeatable reads
phantom read
things isolation level
RU Read Uncommitted dirty read / unrepeatable read / phantom read. NA MVCC read, you can read what other transactions from modifying or even uncommitted.
RC Read Committed unrepeatable read / phantom reads. Modify other transactions to the database, as long as has been submitted to modify its result is visible, and the order of these two matters unrelated to the beginning, not fully applicable to read MVCC.
RR repeatable read phantom read. Fully applicable to MVCC, can only read modify transaction to the database before it starts already submitted,
after it started, all other transactions not visible to amend the terms of its database.
S serialization /. Completely unsuitable applicable MVCC, so that all of the query will be locked, then it must wait after the transaction.
Oracle Postgresql default RC
MySQL Innodb RR default
method InnoDB realization of MVCC: multi-version concurrency control
method to achieve InnoDB is MVCC, which stores three additional hidden field for each row.
1.DB_TRX_ID 6byte process of identifying each transaction, whose value is automatically +1
creation time "and" Delete Time "is the value DB_TRX_ID records
such as insert, update, expressed as a bit when the delete operation
2.DB_ROLL_PTR: size is 7byte, pointing written rollback segment (rollback) of an undo log record
(update operation, then the value before the recording ROW Update)
3.DB_ROW_ID: size 6byte, the value increases monotonically newly inserted row increased accumulation when a clustered index automatically by innodb index (ie not the primary key, because MYSQL default clustered tables, automatically generate a the ROWID)
DB_TRX_ID recorded when the time to create rows deleted occurred at a time in each event, each time line store version number, rather than storing the actual event. Every time things start this version will increase. Since the beginning of recorded time, the system will keep a record of each version of things.
. a new, operating in insert "creation time" = DB_TRX_ID, at this time, "Delete Time" is undefined;
. b changes in the update, the new line copy of "creation time" = DB_TRX_ID, delete time undefined, old data rows "creation time" constant, time = delete the transaction DB_TRX_ID;
c delete, delete operation, "create time" corresponding rows of the same, delete = DB_ROW_ID time of the transaction;.
. d query, select for both operations do not modify, read the corresponding data;
the sELECT
Innodb checking each row of data, to ensure that they meet two criteria:
1.InnoDB only find the version earlier than the current transaction version of the row (that is, versions of data rows the transaction must be less than or equal version), which ensures, or is the line created or modified by the current transaction before the line is read by the current transaction transaction already exists.
2. The version of deletion of certain lines are undefined or greater than the version number of the current transaction. Determined before the current transaction began, the line is not deleted in line with the two points above the query results are returned.
INSERT
InnoDB row for each new record created as the current system version number ID.
DELETE
InnoDB record each deleted row to delete the current system version number as the ID line.
UPDATE
InnoDB copy a line. This new line version uses a system version number. It is also the system version number as the deleted version of the line.