MySQL 系列教程（笔记）

# 多版本并发控制

MySQL 的大多数事务型存储引擎实现都不是简单的行级锁。为了提升并发性能，一般都同时实现了多版本并发控制（MVCC）。Oracle、PostgreSQL 等也实现了 MVCC，但各自实现机制不同，因为 MVCC 没有一个统一的实现标准。

可以认为 MVCC 是行级锁的变种，但在很多情况下避免了加锁操作，因此开销更低。虽然实现机制不同，但大都实现了非阻塞的读操作，写操作也只锁定必要的行。

MVCC 的实现，是 通过保存数据在某个时间点的快照来实现的。也就是说，不管需要执行多长时间，每个事物看到的数据都是一致的。根据事物开始的时间不同，每个事物对同一张表，同一时刻看到的数据可能是不一样的。这句话目前笔者就不能完全理解，这个需要熟悉之后，才会理解

前面说到不同存储引擎的 MVCC 实现是不同的，，典型的有乐观锁（optimistic）并发控制和悲观（pessimistic）并发控制

InnoDB 的 MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。一个保存了行的创建时间，一个保存行的过期时间（或删除时间）。存储的不是实际的时间值，而是系统版本号（system version number）。每开始一个新的事物，系统版本号都会自动递增。事物开始时刻的系统版本号会作为事物的版本号，用来和查询到的每行记录的版本号进行比较。下面看一下再 REPEATTABLE READ 隔离级别下，MVCC 具体是如何操作的

  • SELECT：会根据以下两个条件检查每行记录：

    • InnoDB 只查找版本早于当前事物版本的数据行（行的系统版本号小于或等于事物的系统版本号），这可以 确保事物读取的行，要么是在事务开始前已经存在的，要么是事物自身插入或则修改过的。
    • 行的删除版本要么未定义，要么大于当前事物版本号。这可以 确保事物读取到的行，在事物开始之前未被删除。

  • INSERT

    InnoDB 为新插入的每一行保存当前系统版本号作为行版本号

  • DELETE

    InnoDB 为删除的每一行保存当前系统版本号作为行删除标识

  • UPDATE

    InnoDB 为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为删除标识

    保存这两个额外的系统版本号，使大多数读操作都可以不同加锁。使得读取数据操作很简单，性能很好，也能保证读取到符合标准的行。不足的是需要额外的存储空间和更多的行检查工作、额外的维护工作

MVCC 只在 REPEATABLE READ 和 READ COMMITTED 两个级别下工作。其他两个级别不兼容（MVCC 没有正式的规范，由各个存储引擎实现决定），因为 READ UNCOMMITTED 总是读取最新的数据行，而 SERIALIZABLE 则会对所有读取的行都加锁

疑问：笔者这里没有想明白，是否是 MYSQL 的数据行，与 elasticsearch 类似？是不可变的，是通过标记删除旧的数据，让新的数据生效的机制？

← MySQL 的存储引擎 →