Brief MVCC mechanism

MVCC concept :

Called multi-version concurrency control , is a method of concurrency control , usually in database management systems , concurrent access to the database ; and most of the MySQL row-level locking transactional storage engine used in conjunction with

MVCC implementation principle :

MVCC is by saving a snapshot of the data at a point in time to achieve , MVCC primarily for Repeatable-Read ( to avoid dirty alone , the occurrence of cases of non-repeatable read ) transaction isolation level to do , in this isolation level , a and b data shown are isolated from the client , the update is not visible from each other.

Extended:

Dirty read : data submitted is not read out

Can not re-read : before and read many times , the data content is not the same ( the same session , when not modify , always only see the same set of data )

Phantom read : before and read many times , the amount of data is not the same

The Serializable : can prevent dirty reads, non-repeatable read, dummy read from happening. (Serialization)
Repeatable Read : can prevent dirty reads, non-repeatable read from happening. (Repeatable read) does not avoid false read
the Read committed : to avoid dirty reads from happening (read committed)
the Read Uncommitted : the lowest level, the above are not guaranteed. ( Read uncommitted )

MVCC applications:

To innodb , for example in terms of MVCC use

INSERT

InnoDB for each newly inserted row save the current system version as the version number. 
The first transaction ID is 1;

start transaction;
insert into yang values(NULL,'yang') ;
insert into yang values(NULL,'long');
insert into yang values(NULL,'fei');
commit;

In the corresponding data in the table below (two columns are hidden behind, and we can not see through query)

id	name	Created (Transaction ID)	Delete time (transaction ID)
1	that	1	undefined
2	long	1	undefined
3	fei	1	undefined

SELECT

InnoDB checks every two rows in accordance with the following conditions: 
a.InnoDB only to find (the version number of the system is, the system version number less than or equal line transaction) is earlier than the current transaction version of the row, ensuring that the transaction rows read, either before the start of the transaction already exists, either insert their own affairs or modified. 
delete version b. line either undefined or greater than the version number of the current transaction, which can be read to ensure that the transaction OK, not removed before the transaction begins. 
only record a, b meet in order to return as a query result.

DELETE

InnoDB saved for each row to delete the current system version number (ID of the transaction) as a deletion indicator. 
See specific examples below Analysis : 
second transaction , ID 2;

start transaction;
select * from yang;  //(1)
select * from yang;  //(2)
commit;

Hypothesis 1

Assuming the implementation of the transaction ID of the process 2, just performed to (1), then, there is another 3 to the transaction ID is a data table inserted; 
the third transaction ID is 3;

start transaction;
insert into yang values(NULL,'tian');
commit;

In this case the data in the table below :

id	name	Created (Transaction ID)	Delete time (transaction ID)
1	that	1	undefined
2	long	1	undefined
3	fei	1	undefined
4	tian	3	undefined

Then proceed with the transaction 2 (2), since the time of creation of the data id = 4 (transaction ID is 3), the execution of the current transaction ID is 2, and will find the transaction ID InnoDB less than or equal to the current data line transaction ID , the id = 4 data lines is not performed in the transaction 2 (2) are retrieved, retrieved in the transaction data is two select statement 2 will in the following table:

id	name	Created (Transaction ID)	Delete time (transaction ID)
1	that	1	undefined
2	long	1	undefined
3	fei	1	undefined

 

Hypothesis 2

Assuming the implementation of the transaction ID of the process 2, just performed to (1), assuming that the transaction executing the transaction after 3, 4 is subsequently executed the transaction; 
Fourth transaction :

start   transaction;
delete from yang where id=1;
commit;

　　

At this time, the database table is as follows :

 

id	name	Created (Transaction ID)	Delete time (transaction ID)
1	that	1	4
2	long	1	undefined
3	fei	1	undefined
4	tian	3	undefined

　Then performs a transaction ID for the transaction 2 (2), based on a SELECT search condition can be known, it retrieves the created time (ID creating a transaction) less than the current transaction ID row and deletion time (ID delete transaction) is larger than the current transaction row , while the line above id = 4 has already been said, but id = 1 line due to the deletion of the time (deleting the transaction ID) is greater than the current transaction ID, and therefore (2) select * from yang 2 transaction will put id = 1 data retrieved Therefore, the two two select statement transaction data are retrieved as follows:

id	name	Created (Transaction ID)	Delete time (transaction ID)
1	that	1	4
2	long	1	undefined
3	fei	1	undefined

　

UPDATE

InnoDB perform UPDATE, in fact, is a new line inserted record, and save the time of its creation ID of the current transaction, while preserving the current transaction ID to delete the time to UPDATE rows.

Hypothesis 3

假设在执行完事务2的(1)后又执行,其它用户执行了事务3,4,这时，又有一个用户对这张表执行了UPDATE操作: 
第5个事务:

start  transaction;
update yang set name='Long' where id=2;
commit;

　　根据update的更新原则:会生成新的一行,并在原来要修改的列的删除时间列上添加本事务ID,得到表如下:

id	name	创建时间(事务ID)	删除时间(事务ID)
1	yang	1	4
2	long	1	5
3	fei	1	undefined
4	tian	3	undefined
2	Long	5	undefined

继续执行事务2的(2),根据select 语句的检索条件,得到下表:

id	name	创建时间(事务ID)	删除时间(事务ID)
1	yang	1	4
2	long	1	5
3	fei	1	undefined