update一行的时候的时候不是in-place的修改，而是产生一个行的新版本，在新行上修改，最后有点类似copy on write array，在提交的时候切换到新版本。好处是不影响现有数据的读取，一致性好。

概括为：准备数据 + 原子commit 切换版本，和无锁数据结构实现的思路很像，先准备好数据，最后往结构上挂的那一下用CAS原子性保证。MVCC是把一个复杂事务的原子性问题转化到commit动作的原子性上来。

CAS 是一种思想：Conditional Update，后验保证一致，而锁是前验机制。CAS的基本框架

1）读取当前状态 

2）基于读取的状态进行计算得到新状态。

3）Conditional Update：如果计算结果基于的状态没有变，则更新，否则回到第一步。

system model：

Server State A  —— Transaction  T——> Server State B

和一个版本管理系统比如TFS类比：changeset 就是 transaction， changeset number就是 transaction id

每个文件有版本，整个代码库也有版本，都是以changeset number做为版本号。整个代码库的版本历史就是所有的changeset number，是连续的，而文件的版本历史是非连续的，因为不是每个changeset都修改这个文件。

数据库

每个事务分配一个Transaction Id，是自增的。server的当前版本就是上一次成功提交的transaction Id

INNoDB实现MVCC的方法，每一行有2个隐藏字段，记录创建本行的事务ID和删除本行的事务ID（如果被删了的话）

在一个事务中：

对于insert，把当前事务ID填到新行的Create字段

对于delete，把当前事务ID填到要删除的行的Delete字段

对于update，产生一个新行，把旧行标记删除

对于select，返回的记录满足两个条件

1) 行的create事务ID 小于等于Server 当前版本号，（或者等于当前事务ID，本次事务创建的行）这确保读到的数据都是已经提交的

2)行的delete事务ID 大于当前事务ID ，当前事务之后的事务才删除的数据在当前事务可以被读到。

具体的，每个事务会拷贝一个“当前活动事务列表“，用其中最小的那个做为select的上界。相当于在事务开始的时候保存了server的版本号，之后就算有别的事务提交increment了server的版本，当前事务一直用自己保存的那个，Repeatable read。

事务提交就是更新server的当前版本为当前commit的事务号。

标记删除的数据用一个后台janitor定期处理，这个叫purge。

特点
1.MVCC其实广泛应用于数据库技术，像Oracle,PostgreSQL等也引入了该技术，即适用范围广

2.MVCC并没有简单的使用数据库的行锁，而是使用了行级锁，row_level_lock,而非InnoDB中的innodb_row_lock.

基本原理
MVCC的实现，通过保存数据在某个时间点的快照来实现的。这意味着一个事务无论运行多长时间，在同一个事务里能够看到数据一致的视图。根据事务开始的时间不同，同时也意味着在同一个时刻不同事务看到的相同表里的数据可能是不同的。

基本特征
每行数据都存在一个版本，每次数据更新时都更新该版本。
修改时Copy出当前版本随意修改，各个事务之间无干扰。
保存时比较版本号，如果成功（commit），则覆盖原记录；失败则放弃copy（rollback）
InnoDB存储引擎MVCC的实现策略
在每一行数据中额外保存两个隐藏的列：当前行创建时的版本号和删除时的版本号（可能为空，其实还有一列称为回滚指针，用于事务回滚，不在本文范畴）。这里的版本号并不是实际的时间值，而是系统版本号。每开始新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询每行记录的版本号进行比较。

每个事务又有自己的版本号，这样事务内执行CRUD操作时，就通过版本号的比较来达到数据版本控制的目的。

MVCC下InnoDB的增删查改是怎么work的
1.插入数据（insert）:记录的版本号即当前事务的版本号

执行一条数据语句：insert into testmvcc values(1,”test”);

假设事务id为1，那么插入后的数据行如下：

2、在更新操作的时候，采用的是先标记旧的那行记录为已删除，并且删除版本号是事务版本号，然后插入一行新的记录的方式。

比如，针对上面那行记录，事务Id为2 要把name字段更新

update table set name= ‘new_value’ where id=1;

3、删除操作的时候，就把事务版本号作为删除版本号。比如

delete from table where id=1;

4、查询操作：

从上面的描述可以看到，在查询时要符合以下两个条件的记录才能被事务查询出来：

1) 删除版本号未指定或者大于当前事务版本号，即查询事务开启后确保读取的行未被删除。(即上述事务id为2的事务查询时，依然能读取到事务id为3所删除的数据行)

2) 创建版本号 小于或者等于 当前事务版本号 ，就是说记录创建是在当前事务中（等于的情况）或者在当前事务启动之前的其他事物进行的insert。

（即事务id为2的事务只能读取到create version<=2的已提交的事务的数据集）

补充：

1.MVCC手段只适用于Msyql隔离级别中的读已提交（Read committed）和可重复读（Repeatable Read）.

2.Read uncimmitted由于存在脏读，即能读到未提交事务的数据行，所以不适用MVCC.

原因是MVCC的创建版本和删除版本只要在事务提交后才会产生。

3.串行化由于是会对所涉及到的表加锁，并非行锁，自然也就不存在行的版本控制问题。

4.通过以上总结，可知，MVCC主要作用于事务性的，有行锁控制的数据库模型。

关于Mysql中MVCC的总结
客观上，我们认为他就是乐观锁的一整实现方式，就是每行都有版本号，保存时根据版本号决定是否成功。

但由于Mysql的写操作会加排他锁（前文有讲），如果锁定了还算不算是MVCC？

了解乐观锁的小伙伴们，都知道其主要依靠版本控制，即消除锁定，二者相互矛盾，so从某种意义上来说，Mysql的MVCC并非真正的MVCC，他只是借用MVCC的名号实现了读的非阻塞而已。