mysql mvcc

MVCC (Multi Version Concurrency Control的简称)，代表多版本并发控制，用于支持RC(读已提交)和RR(可重复读)隔离级别的实现。在一个支持MVCC的并发系统中， 我们需要支持两种读， 一个是快照读， 一个是当前读。

MVCC最大的 优势 ：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能。

事务日志可以帮助提高事务的效率。使用事务日志，存储引擎在修改表的数据时只需要修改其 内存拷贝 (可理解为缓存)，再把该修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘。事务日志采用的是追加的方式，因此写日志的 *** 作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快得多。事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回到磁盘。目前大多数存储引擎都是这样实现的，我们通常称之为预写式日志（Write-Ahead Logging），修改数据需要写两次磁盘。

如果数据的修改已经记录到事务日志并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动恢复这部分修改的数据。

MySQL Innodb中跟数据持久性、一致性有关的日志，有以下几种：

MVCC是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的删除时间。当然存储的并不是实际的时间值，而是系统版本号（system version number)。每开始一个新的事务， 系统版本号 都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。

下面看一下在RR隔离级别下，MVCC具体是如何 *** 作的。

保存这两个额外系统版本号，使大多数读 *** 作都可以不用加锁。这样设计使得读数据 *** 作很简单，性能很好，并且也能保证只会读取到符合标准的行，不足之处是每行记录都需要额外的存储空间，需要做更多的行检查工作，以及一些额外的维护工作。

RC隔离级别下，其实整个过程几乎一样，只是每次select的时候，都会生成一个快照，即增加版本号。读已提交就是在一次事务中，可以查询到新提交的数据。

MVCC 全称Multi-Version Concurrency Control，其好处是读不加锁，读写不冲突，并发性能好

对于使用 READ COMMITTED 和 REPEATABLE READ 隔离级别的事务来说，都必须保证读到已提交事务修改过的记录，也就是说假如另一个事务修改了记录但尚未提交，是不能读取最新版本的记录的，其核心问题：需要判断 MVCC 版本链中的哪个版本是当前事务可见的。innodb 的解决方案 readView，readView 包含4个比较重要的属性

本文作者 ： 潜行前行

本文链接 ： https://www.cnblogs.com/cscw/p/16106338.html

---