MVCC

MySQL 的大多数事务型存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑，它们一般都同时实现了多版本并发控制（MVCC）。

MVCC 是行级锁的一种变种。多数情况下避免了加锁操作，因此开销更低。

MVCC 是通过保存数据在某个时间点的快照来实现。不管执行多长时间，每个事务看到的数据是一致的。根据事务开始的时间不同，每个事务对同一张表、同时刻看到的数据是不一样的。

典型的 MVCC 的实现有：乐观（optimistic）并发控制和悲观（pessimistic）并发控制。

MVCC 如何工作

下面通过 InnoDB 的简化版行为介绍

InnoDB 的 MVCC 是通过每行记录后面保存的两个隐藏的列来实现的。这两个列分别是：

  • 行的创建时间
  • 行的过期时间（或删除时间）

当然实际存储的并不是实际的时间值，而是系统版本号（system version number）。每个新的事务，系统版本号都会自动递增。事务开始时刻的版本号会作为事务的版本号，用于和查询到的每行记录的版本号进行比较。

下面在 _REPEATABLE READ_ 隔离级别下，MVCC 如何操作的。

  • SELECT
    • InnoDB 根据以下条件检查每行记录：
      • InnoDB 只查找版本早于当前事务版本的数据行（即：行的版本号<=事务的系统版本号）
        • 可确保事务读取的行，要么在事务开始前已存在，要么在事务自身插入或修改过的
      • 行的删除版本要么未定义，要么大于当前事务版本号
        • 可确保事务读取到的行，在事务之前未被删除
  • INSERT
    • InnoDB 为新插入的每一行，保存当前系统版本号作为行版本号。
  • DELETE
    • InnoDB 为删除的每一行，保存当前系统版本号作为行删除版本号。
  • UPDATE
    • • InnoDB 为新插入一行，保存当前系统版本号作为行版本号；同时保存当前系统的版本号到原来的行作为行删除标识。

MVCC 优劣势、特点

优势：

  • 保存这两个系统版本号，是大多数读操作可不用加锁
  • 读数据操作更简单，性能更好，也能保证只会读取到符合标准的行

不足：

  • 每行记录需要额外的存储空间，需要做更多的行检查工作及维护工作

特点：

  • MVCC 只在 REPEATABLE READ 和 READ COMMITTED 两个隔离级别下工作。其他两个级别与 MVCC 不兼容；（MVCC 没有正式的规范，各引擎和数据库的实现各异，因此不可说实现方式是错误的。）
    • 因为 READ UNCOMMITED 总是读取最新的数据行，不符合当前事务版本的数据行；
    • 而 SERIALIZABLE 则会多所有读取的行都加锁。