MVCC的实现原理：

InnoDB对每一行都加上了两个隐藏的列，其中一列存储行被修改的时系统的修改版本号，另外一列存储行被删除时的系统的删除版本号，以此实现了读不加锁、读写不冲突（不需要等待访问行上的锁释放，读取行的一个快照）。在读多写少的应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能。

MVCC的具体流程：

拿InnoDB在repeatable read隔离级别下来举例：

每当一个事务开始的时候，InnoDB都会给这个事务分配一个递增的版本号

在插入记录时，记录的创建版本号修改为当前事务版本号

在删除记录时，记录的删除版本号修改为当前事务版本号，做个删除的标记，在purge操作时才进行判断删除

在更新操作时，先标记旧记录为已删除，并将删除版本号改为当前事务版本号，然后插入一行新记录

在读取操作时，判断两个条件，都满足就返回（1、读取记录的修改版本号小于或等于当前事务版本号，即改行记录是在该事务中或者事务前进行修改  2、行的删除版本号要么没有被定义，即改行记录未被删除或更新，要么删除版本号大于当前事务版本号）

MVCC的优缺点：

优点：InnoDB几乎不用获得任何锁，每个查询都通过版本检查来获得自己需要的数据版本，从而大大提高系统的并发性

缺点：每行记录都需要额外的存储空间，更多的行检查工作和一些额外的维护工作

MVCC的注意事项：

各隔离级别MVCC的效果：

只有read-committed（读取的是行数据的最新版本）和 repeatable-read 两种事务隔离级别才能使用MVCC

read-uncommited由于是读到未提交的，所以不存在版本的问题

serializable 则会对所有读取的行加锁，也就没有必要用到MVCC

 

各隔离级别MVCC关于快照定义：

在read-committed隔离级别下，对于快照数据，mvcc总是读取被锁定行的最新一份快照数据

repeatable-read则是读取事务开始时的行数据版本

(注：如果有事务A进行select操作，事务B进行delect操作，那么当事务B提交后：如果在read-committed级别，则A读到最新数据历史数据(空集)，而repeatable-read读到事务开始时的行数据版本，则还是和未提交前的一样)