先重申下隔离级别的特性 | 隔离级别 | 脏读可能性 | 不可重复可能性 | 幻读可能性 | 加锁读 | | --- | --- | --- | --- | --- | | READ UNCOMMITTED | Yes | Yes | Yes | No | | READ COMMITTED | No | Yes | Yes | No | | REPEATABLE READ | No | No | Yes | No | | SERIALIZABLE | No | No | No | Yes | ### MVCC机制 InnoDB的**一致性的非锁定读**就是通过在MVCC实现的，Mysql的大多数事务型存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑，它们一般都同时实现了多版本并发控制（MVCC）。MVCC的实现，是通过保存数据在某一个时间点的快照来实现的。因此每一个事务无论执行多长时间看到的数据，都是一样的。所以MVCC实现可重复读。 * 快照读：select语句默认，不加锁，MVCC实现可重复读，使用的是MVCC机制读取undo中的已经提交的数据。所以它的读取是非阻塞的 * 当前读：select语句加S锁或X锁；所有的修改操作加X锁，在select for update 的时候，才是当地前读。 *RR隔离级别下的快照读，不是以begin开始的时间点作为snapshot建立时间点，而是以第一条select语句的时间点作为snapshot建立的时间点。* # 什么是MVCC? 英文全称为Multi-Version Concurrency Control,翻译为中文即 多版本并发控制。在小编看来，他无非就是乐观锁的一种实现方式。在Java编程中，如果把乐观锁看成一个接口，MVCC便是这个接口的一个实现类而已。  # 特点 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的名号实现了读的非阻塞而已。