关于mysql:mysql-系列MVCC

MVCC 全称是 Multiversion concurrency control，即 多版本并发管制 。从它的名字就能够看出是对于在并发时对 读写管制 的一种办法，根本市面上风行的 Database 都有其具体的实现。

MVCC 使得 各个事务 在读写数据时能最大水平的升高锁的依赖，在保障事务隔离性的同时，也能让读类型的事务和写操作的事务并发进行。

当咱们在进行批改操作时，MVCC 会通过 undo log 保留了之前的数据记录，就像每条记录都有本人的历史版本一样。

通过这些 历史版本 的追溯，MVCC 就再也不怕写操作的影响了，这就是 MVCC 的精华所在了。

咱们晓得，在事务的四大个性中有 隔离性 的存在，而它的实现离不开锁的使用。然而锁有它的性能瓶颈，比方须要 排队期待 或者一不小心就产生死锁等等。

而在有了 MVCC 多版本控制 后，读写操作再也不必小心翼翼的防着对方，大大提高了数据库的 并发解决。

当然，这针对的是读和写的并发状况，如果是写和写的同时操作，那么原来该怎么管制就得怎么管制，这是波及到数据的 完整性 准则了。

所以，MVCC 次要是优化了 读写并发 的操作，对于很多 读多写少 的互联网我的项目，曾经能达到优化的目标了。

在说 MVCC 的具体原理之前，咱们先来介绍下 undo log，它在 MVCC 里施展了很大的作用。

undo log 是对事务操作时的一个日志记录，以提供数据回滚性能。比方当初事务进行了 insert 操作，则回滚时会逆向解析为 delete；如果是 delete 操作，则变为 insert 操作，相当于一种逻辑的反向操作。

而 undo log 除了记录下每一次的操作类型、数据状况和事务 ID 外，还蕴含了一个指针：即上一次的记录指针，以造成残缺的历史链路。

所以 MVCC 历史版本数据就来是从 undo log 的记录指针去追溯获取的。那么，最近一次的记录指针是寄存在哪里呢？

实际上，每当咱们插入一行数据的时候，数据库还会额定的帮咱们生成 2 个隐形字段：

这一行的 DB_ROLL_PTR 也就是最近一次的记录指针了，这样的话，每次须要追溯历史版本，就能够从这开始了。

后面提及到事务的隔离性，隔离性是有四个隔离级别的：未提交读、已提交读、可反复读、可串行化。而事实上 MVCC 只在 已提交读 、 可反复读 隔离级别上实现了。

因为 未提交读 要求最低，不管三七二十一，只有能获取到数据就返回了。而 可串行化 天生就把别的申请挡在里面了，不必思考事务之间的并发执行了。

在 已提交读 、 可反复读 的隔离级别上，MVCC 也会有所不一样的，次要体现在 Read View 的生成上。

Read View 是对过后所沉闷的事务 id 的保护，蕴含的字段如下：

当把这些事务 id 保护到以后事务的 Read View 里后，就能够管制其余事务对以后事务的可见性了。

比方以后 Read View 的 m_low_limit_id 是 10，那即便前面又有新的事务产生，以后事务也只能读取到这个 id 为 10 的事务为止，毕竟前面的事务是属于新来的。

又比方以后事务须要回滚了，则会依据 undo log 的记录指针以及 Read View 的 m_up_limit_id 去管制回滚。

解释了 Read View 的作用后，咱们持续讲讲已提交读、可反复读在 MVCC 上的不同。

对于已提交读，它在每次 SELECT 的时候都会从新生成 Read View，所以已提交读在同一事务里将有可能读到不一样的提交数据！

而可反复读只在第一次 SELECT 的时候生成，所以前面读取到的数据都在此处的版本控制内！

对于 MVCC 在 undo log 里所产生的历史版本也不会始终存着，在满足肯定条件后则会被标记为革除状态，期待清理。

像对于 insert 类型的 undo log 则能够在提交事务后就标记为革除状态了，因为这是属于新增的，不会有其余事务依赖到。

MVCC 通过 undo log 的记录指针取得了一个个的历史版本，就像镜像备份一样，使得数据的读写不用再依赖一份数据，进步了并发执行效率。

不过，undo log 革除线程比拟滞后的话，将会导致 undo log 越来越大，影响磁盘操作效率。必要的时候须要配置一些零碎变量以调配更多的资源给革除线程。

总体来讲，MVCC 的应用是有意义的，就像空间换工夫一样，在这里就是 冗余版本换并发性能 了。

感兴趣的敌人能够搜一搜公众号「阅新技术」，关注更多的推送文章。
能够的话，就顺便点个赞、留个言、分享下，感激各位反对！
阅新技术，浏览更多的新常识。

MVCC 介绍