MySQL多版本并发控制MVCC

什么是MVCC

MVCC就是多版本并发控制。

MySQL的事务型存储引擎通过多版本并发控制（MVCC）来提升并发性能。

可以认为MVCC是行级锁的一个变种，但是它在大多数情况下避免了加锁操作，同时实现非阻塞的读操作，因此开销更低。

MVCC是通过保存数据在某个时间点的快照来实现的，核心思想就是保存数据的历史版本，通过对数据行的多个版本管理来实现数据库的并发控制。

这样我们就可以通过比较版本号决定数据是否显示出来，读取数据的时候不需要加锁也可以保证事务的隔离效果。

MVCC的实现

实际上，InnoDB 会在每行记录后面增加三个隐藏字段：

• ROW_ID：行ID，随着插入新行而单调递增，如果有主键，则不会包含该列。
• TRX_ID：记录插入或更新该行的事务的事务ID。
• ROLL_PTR：回滚指针，指向 undo log 记录。每次对某条记录进行改动时，该列会存一个指针，可以通过这个指针找到该记录修改前的信息。当某条记录被多次修改时，该行记录会存在多个版本，通过 ROLL_PTR 链接形成一个类似版本链的概念。

以 RR 级别为例：

每开启一个事务时，系统会给该事务分配一个事务 Id，在该事务执行第一 个 select 语句的时候，会生成一个当前时间点的事务快照 ReadView，主要包含以下几个属性：

• m_ids：表示生成ReadView时，当前系统中未提交的读写事务的事务id列表。
• min_trx_id：表示生成ReadView时，当前系统中未提交的读写事务中最小的事务id，也就是m_ids中的最小值。
• max_trx_id：表示生成ReadView时，系统中应该分配给下一个事务的id值。
• creator_trx_id：表示生成ReadView时，该事务的事务id。

有了这个 ReadView，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见：

• trx_id == creator_trx_id：可以访问这个版本。
• trx_id < min_trx_id ：可以访问这个版本。
• trx_id > max_trx_id：不可以访问这个版本。
• min_trx_id <= trx_id <= max_trx_id ：如果trx_id是在m_ids中，不可以访问这个版本，反之可用。

在进行判断时，首先会拿记录的最新版本来比较，如果该版本无法被当前事务看到，则通过记录的 ROLL_PTR 找到上一个版本，重新进行比较，直到找到一个能被当前事务看到的版本。
而对于删除，其实就是一种特殊的更新，InnoDB 用一个额外的标记位 delete_bit 标识是否删除。当我们在进行判断时，会检查下 delete_bit 是否被标记，如果是，则跳过该版本，通过 ROLL_PTR 拿到下一个版本进行判断。

以上内容是对于 RR 级别来说，而对于 RC 级别，其实整个过程几乎一样，唯一不同的是生成 ReadView 的时机， RR 级别只在事务开始时生成一次，之后一直使用该 ReadView。而 RC 级别则在每次 select 时，都会生成一个 ReadView。

MVCC 有没有解决幻读？

幻读：在一个事务中使用相同的 SQL 进行两次读取，第二次读取到了其他事务新插入的行。
例如：

1）事务 1 第一次查询：select * from user where id < 10 时查到了 id = 1 的数据

2）事务 2 插入了 id = 2 的数据

3）事务 1 使用同样的语句第二次查询时，查到了 id = 1、id = 2 的数据，出现了幻读。

谈到幻读，首先我们要引入“当前读”和“快照读”的概念。

• 快照读：生成一个事务快照（ReadView），之后都从这个快照获取数据。普通 select 语句就是快照读。
• 当前读：读取数据的最新版本。常见的 update/insert/delete、还有 select ... for update、select ... lock in share mode 都是当前读。

对于快照读，MVCC 因为从 ReadView 读取，所以必然不会看到新插入的行，所以天然就解决了幻读的问题。

而对于当前读的幻读，MVCC 是无法解决的。需要使用 Gap Lock 或 Next-Key Lock（Gap Lock + Record Lock）来解决。

其实原理也很简单，用上面的例子稍微修改下以触发当前读：

select * from user where id < 10 for update

当使用了 Gap Lock 时，Gap 锁会锁住 id < 10 的整个范围，因此其他事务无法插入 id < 10 的数据，从而防止了幻读。