mysql版本号锁_关于MySQL如何多版本并发控制MVVC mvvc和乐观锁

web 前端中文站认为，多版本并发控制只针对 innodb 的 repeatable read 和 read committed 这两种隔离级别。多版本并发控制的原理就是在每个记录行后面增加两个标示列用来存储该行的状态，分别存储改行的新系统版本号和删除系统版本号。系统的版本号会随着每增加一个事务递增。

在前端框架的设计模式当中，MVVC 一词很常见，但是 MySQL 中的?MVVC 和前端框架中所代表的意思完全不一样。在 MySQL?中 MVVC 一词代表的是多版本并发控制。下面让我们来尝试着学习它。

MVCC 的全称是“多版本并发控制”。这项技术使得 InnoDB 的事务隔离级别下执行一致性读操作有了保证，换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值。这是一个可以用来增强并发性的强大的技术，因为这样的一来的话查询就不用等待另一个事务释放锁。这项技术在数据库领域并不是普遍使用的。一些其它的数据库产品，以及 mysql 其它的存储引擎并不支持它。

mysql 的 innodb 采用的是行锁，而且采用了多版本并发控制来提高读操作的性能。

什么是多版本并发控制呢 ？其实就是在每一行记录的后面增加两个隐藏列，记录创建版本号和删除版本号，

而每一个事务在启动的时候，都有一个唯一的递增的版本号。

在 InnoDB 中，给每行增加两个隐藏字段来实现 MVCC，两个列都用来存储事务的版本号，每开启一个新事务，事务的版本号就会递增。

于是乎，默认的隔离级别(REPEATABLE READ)下，增删查改变成了这样：

SELECT

读取创建版本小于或等于当前事务版本号，并且删除版本为空或大于当前事务版本号的记录。这样可以保证在读取之前记录是存在的。

INSERT

将当前事务的版本号保存至行的创建版本号

UPDATE

新插入一行，并以当前事务的版本号作为新行的创建版本号，同时将原记录行的删除版本号设置为当前事务版本号

DELETE

将当前事务的版本号保存至行的删除版本号

在插入操作时 ： 记录的创建版本号就是事务版本号。

比如我插入一条记录, 事务 id 假设是 1 ，那么记录如下：也就是说，创建版本号就是事务版本号。

id

name

create version

delete version

1

lisa33xiaoq.net

1

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

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

update table set name= 'new_value' where id=1;

id

name

create version

delete version

1

lisa33xiaoq.net

1

2

1

lisa33xiaoq.net

2

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

delete from table where id=1;

id

name

create version

delete version

1

lisa33xiaoq.net

2

3

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

删除版本号 大于 当前事务版本号，就是说删除操作是在当前事务启动之后做的。

创建版本号 小于或者等于 当前事务版本号 ，就是说记录创建是在事务中(等于的情况)或者事务启动之前。

这样就保证了各个事务互不影响。从这里也可以体会到一种提高系统性能的思路，就是：通过版本号来减少锁的争用。另外，只有 read-committed 和 repeatable-read 两种事务隔离级别才能使用 mVcc read-uncommited 由于是读到未提交的，所以不存在版本的问题。而 serializable 则会对所有读取的行加锁。

快照读和当前读

快照读：读取的是快照版本，也就是历史版本

当前读：读取的是最新版本

普通的 SELECT 就是快照读，而 UPDATE、DELETE、INSERT、SELECT … ?LOCK IN SHARE MODE、SELECT … FOR UPDATE 是当前读。

锁定读

在一个事务中，标准的 SELECT 语句是不会加锁，但是有两种情况例外。SELECT … LOCK IN SHARE MODE 和 SELECT … FOR UPDATE。

SELECT ... LOCK IN SHARE MODE

给记录假设共享锁，这样一来的话，其它事务只能读不能修改，直到当前事务提交

SELECT ... FOR UPDATE

给索引记录加锁，这种情况下跟 UPDATE 的加锁情况是一样的

一致性非锁定读

consistent read (一致性读)，InnoDB 用多版本来提供查询数据库在某个时间点的快照。如果隔离级别是 REPEATABLE READ，那么在同一个事务中的所有一致性读都读的是事务中第一个这样的读读到的快照；如果是 READ COMMITTED，那么一个事务中的每一个一致性读都会读到它自己刷新的快照版本。Consistent read(一致性读)是 READ COMMITTED 和 REPEATABLE READ 隔离级别下普通 SELECT 语句默认的模式。一致性读不会给它所访问的表加任何形式的锁，因此其它事务可以同时并发的修改它们。

悲观锁和乐观锁

悲观锁，正如它的名字那样，数据库总是认为别人会去修改它所要操作的数据，因此在数据库处理过程中将数据加锁。其实现依靠数据库底层。

乐观锁，如它的名字那样，总是认为别人不会去修改，只有在提交更新的时候去检查数据的状态。通常是给数据增加一个字段来标识数据的版本。

MVCC 实现一致性非锁定读，这就有保证在同一个事务中多次读取相同的数据返回的结果是一样的，解决了不可重复读的问题。

web 前端中文站点评：

因为在缓存中有一个用于维护锁的资源，对锁的维持需要占用消耗 mysql 的资源，多版本并发控制这一原理是减少了用于维持锁资源的消耗来提高性能，因此日志的写操作建议先 undo 再 redo。

【注：本文源自网络文章资源，由站长整理发布】

web 前端中文站 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权

转载请注明原文链接：关于 MySQL 如何多版本并发控制 MVVC mvvc 和乐观锁