前言
在一些大厂面试的时候可能面试官会问到这样一个问题:"谈谈你对 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(回滚段) 中旧记录链,它的执行流程如下:
- 比如一个有个事务插入 test 表插入了一条新记录,记录如下,name 为 ninglz,隐式主键是 1,事务 ID 和回滚指针,我们假设为 NULL。
- 现在来了一个事务 1 对该记录的 name 做出了修改,改为 Jerry
- 在事务 1 修改该行(记录)数据时,数据库会先对该行加排他锁。
- 然后把该行数据拷贝到 undo log 中,作为旧记录,既在 undo log 中有当前行的拷贝副本。
- 拷贝完毕后,修改该行 name 为 Jerry,并且修改隐藏字段的事务 ID 为当前事务 1 的 ID, 我们默认从 1 开始,之后递增,回滚指针指向拷贝到 undo log 的副本记录,既表示我的上一个版本就是它。
- 事务提交后,释放锁。
- 事务 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是此条记录已经是不活跃状态则可以查询到
}
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。
版本链比对规则:
- 如果 row 的 DB_TRX_ID 落在( DB_TRX_ID < up_limit_id ),表示这个版本是已提交的事务生成的,这个数据是可见的;
- 如果 row 的 DB_TRX_ID 落在( DB_TRX_ID >= low_limit_id ),表示这个版本是由将来启动的事务生成的,是不可见的(若 row 的 DB_TRX_ID 就是当前自己的事务是可见的);
- 如果 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 版本链比对机制,使得不同的事务会根据数据版本链对比规则读取 同一条数据在版本链上的不同版本数据。