mysql 并发_MySQL深入到放弃(八):多版本并发控制

前言

在一些大厂面试的时候可能面试官会问到这样一个问题:"谈谈你对 MySQL 的 MVCC 的理解？"，MVCC 其实是 MySQL 里面一个比较底层的东西。这章将给大家介绍 MVCC 机制，MySQL 如何通过 MVCC 实现事务隔离。

MVCC 多版本并发控制

MVCC，全称 Multi-Version Concurrency Control，即多版本并发控制。MVCC 是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。

MySQL 在可重复读隔离级别下如何保证事务较高的隔离性，同样的 SQL 查询语句在一个事务里多次执行查询结果相同，就算其它事务对数据有修改也不会影响当前事务 SQL 语句的查询结果。这个隔离性就是靠 MVCC 机制来保证的。

MVCC 在 MySQL InnoDB 中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读。

MySQL 在读已提交和可重复读隔离级别下都实现了 MVCC 机制。

什么是当前读和快照读？

在学习 MVCC 多版本并发控制之前，我们必须先了解一下，什么是 MySQL InnoDB 下的当前读和快照读。

当前读

像 select lock in share mode(共享锁，S 锁), select for update ; , update, insert ,delete(排他锁，X 锁)这些操作都是一种当前读，那么为什么叫当前读？

当前读就是它读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。当前读实际上是一种加锁的操作，是悲观锁的实现。

快照读

像不加锁的 select 操作就是快照读，即不加锁的非阻塞。

快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读。

之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，即 MVCC，可以认为 MVCC 是行锁的一个变种，但它在很多情况下，避免了加锁操作，降低了开销。既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。

MVCC 就是为了实现读-写冲突不加锁，而这个读指的就是快照读, 而非当前读。

当前读，快照读和 MVCC 的关系

准确的说，MVCC 多版本并发控制指的是 “维持一个数据的多个版本，使得读写操作没有冲突” 的概念。

而在 MySQL 中，实现 MVCC 概念，我们就需要 MySQL 提供具体的功能去实现它，而快照读就是 MySQL 为我们实现 MVCC 模型的其中一个具体非阻塞读功能。而相对而言，当前读就是悲观锁的具体功能实现。

MVCC 解决的问题

数据库并发场景有三种，分别为：

• 读-读：不存在任何问题，也不需要并发控制

• 读-写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读

• 写-写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失

MVCC 带来的好处

多版本并发控制(MVCC)是一种用来解决读-写冲突的无锁并发控制，也就是为事务分配单向增长的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，读操作只读该事务开始前的数据库的快照。所以 MVCC 可以为数据库解决以下问题：

• 在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能。

• 同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题。

MVCC 就是不满意只让数据库采用悲观锁这样性能不佳的形式去解决读-写冲突问题而提出的解决方案。所以在数据库中，因为有了 MVCC，我们可以形成两个组合：

• MVCC + 悲观锁：MVCC 解决读写冲突，悲观锁解决写写冲突

• MVCC + 乐观锁：MVCC 解决读写冲突，乐观锁解决写写冲突

这种组合的方式就可以最大程度的提高数据库并发性能，并解决读写冲突，和写写冲突导致的问题。

MVCC 的实现原理

MVCC 的目的就是多版本并发控制，在数据库中的实现，就是为了解决读写冲突，它的实现原理主要是依赖记录中的 3 个隐式字段，undo 日志 ，Read View 来实现的。所以我们先来看看这个三个的概念

隐式字段

每行记录除了我们自定义的字段外，还有数据库隐式定义的DB_TRX_ID,DB_ROLL_PTR,DB_ROW_ID等字段:

• DB_TRX_ID

  6 byte，最近修改(修改/插入)事务 ID：记录创建这条记录或最后一次修改该记录的事务 ID。

• DB_ROLL_PTR

  7 byte，回滚指针，指向这条记录的上一个版本(存储于 rollback segment 里)。

• DB_ROW_ID

  6 byte，隐含的自增 ID (隐藏主键)，如果数据表没有主键，InnoDB 会自动以 DB_ROW_ID 产生一个聚簇索引。

• 实际还有一个删除标识 flag 隐藏字段, 既记录被更新或删除并不代表真的删除，而是删除标识 flag 变了。

如上图，DB_ROW_ID是数据库默认为该行记录生成的唯一隐式主键，DB_TRX_ID是当前操作该记录的事务 ID,而DB_ROLL_PTR是一个回滚指针，用于配合 undo 日志，指向上一个旧版本。

undo 日志

undo 日志用于存放数据修改被修改前的值，假设修改 test 表中 id=2 的行数据，把 name=’B’ 修改为 name = ‘B2’ ，那么 undo 日志就会用来存放 name=’B’ 的记录，如果这个修改出现异常，可以使用 undo 日志来实现回滚操作，保证事务的一致性。

对数据的变更操作，undo log 中分为两种类型：

• insert undo log

  代表事务在 insert 新记录时产生的 undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃。

• update undo log

  事务在进行 update 或 delete 时产生的 undo log。不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被 purge 线程统一清除。

purge

• 为了实现 InnoDB 的 MVCC 机制，更新或者删除操作都只是设置一下老记录的 flag，并不真正将过时的记录删除。

• 为了节省磁盘空间，InnoDB 有专门的 purge 线程来清理 flag 为 true 的记录。

对 MVCC 有帮助的实质是 update undo log ，undo log 实际上就是存在 rollback segment(回滚段) 中旧记录链，它的执行流程如下：

1. 比如一个有个事务插入 test 表插入了一条新记录，记录如下，name 为 ninglz，隐式主键是 1，事务 ID 和回滚指针，我们假设为 NULL。

2. 现在来了一个事务 1 对该记录的 name 做出了修改，改为 Jerry

• 在事务 1 修改该行(记录)数据时，数据库会先对该行加排他锁。
• 然后把该行数据拷贝到 undo log 中，作为旧记录，既在 undo log 中有当前行的拷贝副本。
• 拷贝完毕后，修改该行 name 为 Jerry，并且修改隐藏字段的事务 ID 为当前事务 1 的 ID, 我们默认从 1 开始，之后递增，回滚指针指向拷贝到 undo log 的副本记录，既表示我的上一个版本就是它。
• 事务提交后，释放锁。

3. 事务 2 修改 test 表的同一个记录，将 name 修改为 Tom

• 在事务 2 修改该行数据时，数据库也先为该行加锁。
• 然后把该行数据拷贝到 undo log 中，作为旧记录，发现该行记录已经有 undo log 了，那么最新的旧数据作为链表的表头，插在该行记录的 undo log 最前面。
• 修改该行 name 为 Tome，并且修改隐藏字段的事务 ID 为当前事务 2 的 ID, 那就是 2，回滚指针指向刚刚拷贝到 undo log 的副本记录。
• 事务提交，释放锁。

从上面，我们就可以看出，不同事务或者相同事务的对同一记录的修改，会导致该记录的 undo log 成为一条记录版本线性表，既链表，undo log 的链首就是最新的旧记录，链尾就是最早的旧记录(当然就像之前说的该 undo log 的节点可能是会 purge 线程清除掉，像图中的第一条 insert undo log，其实在事务提交之后可能就被删除丢失了，不过这里为了演示，所以还放在这里)

Read View(读视图)

Read View 就是事务进行快照读操作的时候生产的读视图(Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的 ID(当每个事务开启时，都会被分配一个 ID, 这个 ID 是递增的，所以最新的事务， ID 值越大)。

Read View 主要是用来做可见性判断的, 即当我们某个事务执行快照读的时候，对该记录创建一个 Read View 读视图，把它比作条件用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的 undo log 里面的某个版本的数据。

Read View 遵循一个可见性算法，主要是将要被修改的数据的最新记录中的 DB_TRX_ID(即当前事务 ID)取出来，与系统当前其他活跃事务的 ID 去对比(由 Read View 维护)，如果 DB_TRX_ID 跟 Read View 的属性做了某些比较，不符合可见性，那就通过 DB_ROLL_PTR 回滚指针去取出 Undo Log 中的 DB_TRX_ID 再比较，即遍历链表的 DB_TRX_ID(从链首到链尾，即从最近的一次修改查起)，直到找到满足特定条件的 DB_TRX_ID, 那么这个 DB_TRX_ID 所在的旧记录就是当前事务能看见的最新老版本。

bool changes_visible(trx_id_t    id,const table_name_t& name) constMY_ATTRIBUTE((warn_unused_result)){
  ut_ad(id > 0);
  //如果ID小于Read View中最小的，
  //则这条记录是可以看到。说明这条记录是在select这个事务开始之前就结束的
  if (id   return(true);
  }
  check_trx_id_sanity(id, name);
  //如果比Read View中最大的还要大，
  //则说明这条记录是在事务开始之后进行修改的，所以此条记录不应查看到
  if (id >= m_low_limit_id) {
  return(false);
  } else if (m_ids.empty()) {
  return(true);
  }
  const ids_t::value_type*    p = m_ids.data();
  return(!std::binary_search(p, p + m_ids.size(), id));
  //判断是否在Read View中， 如果在说明在创建Read View时
  //此条记录还处于活跃状态则不应该查询到，否则说明创建Read View是此条记录已经是不活跃状态则可以查询到
}

如上，它是一段 MySQL 判断可见性的一段源码，即 changes_visible 方法(不完全，但能看出大致逻辑)，该方法展示了我们拿 DB_TRX_ID 去跟 Read View 某些属性进行怎么样的比较

在展示之前，我先简化一下 Read View，我们可以把 Read View 简单的理解成有三个全局属性

• trx_list

  一个数值集合，用来维护 Read View 生成时刻系统正活跃的事务 ID

• up_limit_id

  记录 trx_list 列表中事务 ID 最小的 ID

• low_limit_id

  ReadView 生成时刻系统尚未分配的下一个事务 ID，也就是目前已出现过的事务 ID 的最大值+1。

版本链比对规则：

1. 如果 row 的 DB_TRX_ID 落在( DB_TRX_ID < up_limit_id )，表示这个版本是已提交的事务生成的，这个数据是可见的；

2. 如果 row 的 DB_TRX_ID 落在( DB_TRX_ID >= low_limit_id )，表示这个版本是由将来启动的事务生成的，是不可见的(若 row 的 DB_TRX_ID 就是当前自己的事务是可见的)；

3. 如果 row 的 DB_TRX_ID 落在(up_limit_id <= DB_TRX_ID <= low_limit_id)，那就包括两种情况：

   a. 若 row 的 DB_TRX_ID 在视图数组中(活跃状态，还没有 commit)，表示这个版本是由还没提交的事务生成的，不可见(若 row 的 DB_TRX_ID 就是当前自 己的事务是可见的)；

   b. 若 row 的 DB_TRX_ID 不在视图数组中(已 commit)，表示这个版本是已经提交了的事务生成的，可见。

对于删除的情况可以认为是 update 的特殊情况，会将版本链上最新的数据复制一份，然后将 trx_id 修改成删除操作的 trx_id，同时在该条记录的头信息(record header)里的(deleted_flag)标记位写上 true，来表示当前记录已经被 删除，在查询时按照上面的规则查到对应的记录如果 delete_flag 标记位为 true，意味着记录已被删除，则不返回数据。

注意：begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个修改操作 InnoDB 表的语句， 事务才真正启动，才会向 MySQL 申请事务 id，MySQL 内部是严格按照事务的启动顺序来分配事务 id 的。

RC(提交读),RR(可重复读) 级别下的 InnoDB 快照读有什么不同？

正是 Read View 生成时机的不同，从而造成 RC,RR 级别下快照读的结果的不同

• 在 RR 级别下的某个事务的对某条记录的第一次快照读会创建一个快照及 Read View, 将当前系统活跃的其他事务记录起来，此后在调用快照读的时候，还是使用的是同一个 Read View，所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个 Read View，所以对之后的修改不可见。

• 即 RR 级别下，快照读生成 Read View 时，Read View 会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的。而早于 Read View 创建的事务所做的修改均是可见。

• 而在 RC 级别下的，事务中，每次快照读都会新生成一个快照和 Read View, 这就是我们在 RC 级别下的事务中可以看到别的事务提交的更新的原因。

总之在 RC 隔离级别下，是每个快照读都会生成并获取最新的 Read View；而在 RR 隔离级别下，则是同一个事务中的第一个快照读才会创建 Read View, 之后的快照读获取的都是同一个 Read View。

总结

MVCC 机制的实现就是通过 read-view 机制与 undo 版本链比对机制，使得不同的事务会根据数据版本链对比规则读取 同一条数据在版本链上的不同版本数据。