MySQL--MVCC
1、MVCC简介
1.1 什么是MVCC
MVCC(全称Multi-Version Concurrent Control)是一种多版本并发控制机制。
1.2 MVCC是为了解决什么问题
- 大多数MYSQL事务型存储引擎，如InnoDB, Falcon以及PBXT都不使用一种简单的行锁机制。事实上，他们都和MVCC多版本控制一起来使用。
- 锁机制可以控制并发操作，但是其系统开销较大，而MVCC可以在大多数情况下代替行级锁，使用MVCC能降低其系统开销。
1.3 MVCC实现
MVCC是通过保存数据在某个时间点的快照来实现的。不同存储引擎的MVCC实现不同，典型的有乐观并发控制和悲观并发开销。
2、MVCC 具体实现
Innodb的MVCC是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了这个行的创建时间，另一个保存的是行的删除时间。这里存储的并不是实际的时间值，而是系统版本号，每开始一个新的事务，系统版本号就会自动递增，事务开始时刻的系统版本号会作为事务的ID。下面看一下在REPEATABLE READ 隔离级别下，MVCC具体是如何操作的。
2.1 简单的例子
create table user (
uid int primary key auto_increment,
name varchar(20));INSERT
InnoDB为新插入的每一行保存当前系统版本号作为版本号。假设系统的版本号从1开始，第一个事务ID为1.
start transaction;
insert into user values(NULL, 'Hans');
insert into user values(NULL, 'Will');
insert into user values(NULL, 'Jack');
commit;对应的数据中的表如下（后面两列隐藏，我们通过查询语句看不到）
| uid | name | 创建时间（事务ID） | 删除时间（事务ID） |
|---|---|---|---|
| 1 | Hans | 1 | undefined |
| 2 | Will | 1 | undefined |
| 3 | Jack | 1 | undefined |
SELECT
InnoDB会根据以下两个条件检查每行记录，查询结果必须同时满足这两个条件。
1、InnoDB只会查找版本早于当前事务版本的数据行（即行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始前已经存在，要么是事务自身插入或修改过。
2、行的删除版本要么未定义，要么大于当前事务版本号，这可以确保事务读取到的行，在事务开始之前未被删除。
DELETE
InnoDB会为删除的每一行保存当前系统的版本号（事务的ID）作为删除标识。
第二个事务，ID为2
start transaction;
select * from user; //(s 1)
select * from user; //(s 2)
commit;假设1
假设在执行这个事务ID 为2的过程中，刚执行到（s 1），这时，有另一个事务ID为3往这个表里插入了一条数据；
start transaction;
insert into user values(NULL, 'Charles');
commit;这时表中数据如下：
| uid | name | 创建时间() | 删除时间() |
|---|---|---|---|
| 1 | Hans | 1 | undefined |
| 2 | Will | 1 | undefined |
| 3 | Jack | 1 | undefined |
| 4 | Charles | 3 | undefined |
由于user表uid=4的数据创建时间事务ID为3，执行当前事务的ID为2，而InnoDB只会查找事务ID小于等于当前事务ID的数据行，所以uid=4的数据在执行事务2中的（s 2）时不会被检索出来。
假设2
假设子啊执行事务ID为2的过程中，刚执行到(s 1)，事务执行完事务3后，有执行事务4：
start transaction;
delete from user where id=1;
commit;此时数据表如下：
| uid | name | 创建时间() | 删除时间() |
|---|---|---|---|
| 1 | Hans | 1 | 4 |
| 2 | Will | 1 | undefined |
| 3 | Jack | 1 | undefined |
| 4 | Charles | 3 | undefined |
接着执行事务ID为2的事务(s 2)，根据select检索条件知道，它只会检索创建时间小于当前事务ID和删除时间大于当前事务的行。检索出数据如下：
| uid | name | 创建时间() | 删除时间() |
|---|---|---|---|
| 1 | Hans | 1 | 4 |
| 2 | Will | 1 | undefined |
| 3 | Jack | 1 | undefined |
UPDATE
InnoDB执行UPDATE，实际上市新插入了一行记录，并保存期创建时间为当前事务的ID，同时保存当前事务ID到要UPDATE的行的删除时间。
假设3
假设在执行完事务2的(s 1)后，其他用户执行了事务3，4，又有一个用户对这张表执行了UPDATE的操作：
第5个事务：
start transaction;
update user set name='Jucy' where id=2;
commit;得到如下表：
| uid | name | 创建时间() | 删除时间() |
|---|---|---|---|
| 1 | Hans | 1 | 4 |
| 2 | Will | 1 | 5 |
| 3 | Jack | 1 | undefined |
| 4 | Charles | 3 | undefined |
| 2 | Jucy | 5 | undefined |
继续执行事务2的(s 2)，会得到如下表
| uid | name | 创建时间() | 删除时间() |
|---|---|---|---|
| 1 | Hans | 1 | 4 |
| 2 | Will | 1 | 5 |
| 3 | Jack | 1 | undefined |