03 04 2021

前言

MySQL 事务在面试中是高频出现的重灾区,所以我们必须通过理解底层实现,理解大于死记硬背。本文的重点是MySQL事务及MVCC的实现原理。

MySQL 事务

数据库事务

数据库事务( transaction)是访问并可能操作各种数据项的一个数据库操作序列,这些操作要么全部执行,要么全部不执行,是一个不可分割的工作单位。事务由事务开始与事务结束之间执行的全部数据库操作组成。

ACID

谈到事务,一定会谈到事务的特性 ACID:

原子性(Atomicity)

一个事务是一个不可分割的工作单位,其中的操作要么都做,要么都不做;如果事务中一个sql执行失败,则已执行的sql必须回滚,数据库退回到事务前的状态。

一致性(Consistency)

指事务执行结束后,数据库的完整性约束没有被破坏,事务执行的前后都是合法的数据状态。

隔离性(Isolation)

事务内部的操作与其他事务是隔离的,并发执行的各个事务之间不能互相干扰。

持久性(Durability)

持久性是指事务一旦提交,它对数据库的改变就应该是永久性的;接下来的其他操作或故障不应该对该事务有任何影响。

事务隔离级别

数据库的事务隔离级别有四种,分别是读未提交、读已提交、可重复读、序列化,不同的隔离级别下会产生脏读、幻读、不可重复读等相关问题,因此在选择隔离级别的时候要根据应用场景来决定,使用合适的隔离级别。

各种隔离级别和数据库异常情况对应情况如下:

隔离级别 脏读 不可重复读 幻读
READ- UNCOMMITTED
READ-COMMITTED ×
REPEATABLE- READ × ×
SERIALIZABLE × × ×

SQL 标准定义了四个隔离级别:

  • READ-UNCOMMITTED(读取未提交): 事务的修改,即使没有提交,对其他事务也都是可见的。事务能够读取未提交的数据,这种情况称为脏读。
  • READ-COMMITTED(读取已提交): 事务读取已提交的数据,大多数数据库的默认隔离级别。当一个事务在执行过程中,数据被另外一个事务修改,造成本次事务前后读取的信息不一样,这种情况称为不可重复读。
  • REPEATABLE-READ(可重复读): 这个级别是MySQL的默认隔离级别,它解决了脏读的问题,同时也保证了同一个事务多次读取同样的记录是一致的,但这个级别还是会出现幻读的情况。幻读是指当一个事务A读取某一个范围的数据时,另一个事务B在这个范围插入行,A事务再次读取这个范围的数据时,会产生幻读。
  • SERIALIZABLE(可串行化): 最高的隔离级别,完全服从ACID的隔离级别。所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读。

事务隔离机制的实现基于锁机制和并发调度。其中并发调度使用的是MVVC(多版本并发控制),通过保存修改的旧版本信息来支持并发一致性读和回滚等特性。

因为隔离级别越低,事务请求的锁越少,所以大部分数据库系统的隔离级别都是READ-COMMITTED(读取提交内容):,但是你要知道的是InnoDB 存储引擎默认使用 REPEATABLE-READ(可重读)并不会有任何性能损失。

MVCC 多版本并发控制

MVCC

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

要想理解MVCC实现原理,还需要了解以下两个概念:

  • 当前读

    像select lock in share mode(共享锁), select for update ; update, insert ,delete(排他锁)这些操作都是一种当前读,为什么叫当前读?就是它读取的是记录的最新版本,读取时还要保证其他并发事务不能修改当前记录,会对读取的记录进行加锁

  • 快照读(提高数据库的并发查询能力)

    像不加锁的select操作就是快照读,即不加锁的非阻塞读;快照读的前提是隔离级别不是串行级别,串行级别下的快照读会退化成当前读;之所以出现快照读的情况,是基于提高并发性能的考虑,快照读的实现是基于多版本并发控制,即MVCC,可以认为MVCC是行锁的一个变种,但它在很多情况下,避免了加锁操作,降低了开销;既然是基于多版本,即快照读可能读到的并不一定是数据的最新版本,而有可能是之前的历史版本

MVCC多版本并发控制指的是维持一个数据的多个版本,使得读写操作没有冲突,快照读是MySQL为实现MVCC的一个非阻塞读功能。MVCC模块在MySQL中的具体实现是由三个隐式字段,undo日志、read view三个组件来实现的。

MVCC 要解决的问题

数据库并发场景有三种,分别为:

  1. 读读:不存在任何问题,也不需要并发控制
  2. 读写:有线程安全问题,可能会造成事务隔离性问题,可能遇到脏读、幻读、不可重复读
  3. 写写:有线程安全问题,可能存在更新丢失问题

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

  1. 在并发读写数据库时,可以做到在读操作时不用阻塞写操作,写操作也不用阻塞读操作,提高了数据库并发读写的性能。
  2. 解决脏读、幻读、不可重复读等事务隔离问题,但是不能解决更新丢失问题。

MVCC实现原理

MVCC 的实现原理主要依赖于记录中的三个隐藏字段undo logread view来实现的。

隐藏字段

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

DB_TRX_ID

​ 6字节,最近修改事务 id,记录创建这条记录或者最后一次修改该记录的事务 id

DB_ROLL_PTR

​ 7字节,回滚指针,指向这条记录的上一个版本,用于配合 undo log,指向上一个旧版本

DB_ROW_ID

​ 6字节,隐藏的主键,如果数据表没有主键,那么 innodb 会自动生成一个6字节的 row_id

记录如图所示:

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

undo log

​ undo log 被称之为回滚日志,表示在进行 insert,delete,update 操作的时候产生的方便回滚的日志。

​ 当进行 insert 操作的时候,产生的 undo log 只在事务回滚的时候需要,并且在事务提交之后可以被立刻丢弃。

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

purge 线程为了实现InnoDB存储引擎的MVCC机制,当数据发生更新和删除操作的时候都只是设置一下老记录的 deleted_bit,并不是真正的将过时的记录删除,因为为了节省磁盘空间,innodb有专门的 purge 线程来清除 deleted_bit 为true 的记录,如果某个记录的 deleted_bit 为true,并且 DB_TRX_ID 相对于 purge 线程的 read view 可见,那么这条记录一定是可以被安全清除的。

下面我们来看一下undolog生成的记录链

1、假设有一个事务编号为 1 的事务向表中插入一条记录,那么此时行数据的状态为:

2、假设有第二个事务编号为 2 对该记录的 name 做出修改,改为 lisi:

  1. 在事务 2 修改该行记录数据时,数据库会对该行加排他锁;
  2. 然后把该行数据拷贝到 undo log 中,作为 旧记录,即在 undo log 中有当前行的拷贝副本;
  3. 拷贝完毕后,修改该行 name 为 lisi,并且修改隐藏字段的事务id为当前事务 2 的 id,回滚指针指向拷贝到 undo log 的副本记录中;
  4. 事务提交后,释放锁。

3、假设有第三个事务编号为 3 对该记录的 age 做了修改,改为 32:

  1. 在事务 3 修改该行数据的时,数据库会对该行加排他锁;
  2. 然后把该行数据拷贝到 undo log 中,作为旧纪录,发现该行记录已经有 undo log 了,那么最新的旧数据作为链表的表头,插在该行记录的 undo log 最前面;
  3. 修改该行 age 为 32 岁,并且修改隐藏字段的事务 id 为当前事务 3 的 id,回滚指针指向刚刚拷贝的 undo log 的副本记录;
  4. 事务提交,释放锁。

从上述的一系列图中,可以发现,不同事务或者相同事务的对同一记录的修改,会导致该记录的 undo log 生成一条记录版本线性表,即链表,undo log 的链首就是最新的旧记录,链尾就是最早的旧记录。

Read View

Read View 是事务进行快照读操作的时候生产的读视图,在该事务执行快照读的那一刻,会生成一个数据系统当前的快照,记录并维护系统当前活跃事务的 id,事务的 id 值是递增的。

其实 Read View 的最大作用是用来做可见性判断的,也就是说当某个事务在执行快照读的时候,对该记录创建一个 Read View 的视图,把它当作条件去判断当前事务能够看到哪个版本的数据,有可能读取到的是最新的数据,也有可能读取的是当前行记录的 undo log 中某个版本的数据。

Read View 遵循的可见性算法主要是将要被修改的数据的最新记录中的 DB_TRX_ID(当前事务id)取出来,与系统当前其他活跃事务的 id 去对比,如果 DB_TRX_ID 跟 Read View 的属性做了比较,不符合可见性,那么就通过 DB_ROLL_PTR 回滚指针去取出 undo log 中的DB_TRX_ID 做比较,即遍历链表中的 DB_TRX_ID,直到找到满足条件的 DB_TRX_ID,这个 DB_TRX_ID 所在的旧记录就是当前事务能看到的最新老版本数据。

Read View 的可见性规则如下所示:

首先要知道 Read View 中的三个全局属性:

  • trx_list:一个数值列表,用来维护 Read View 生成时刻系统正活跃的事务 ID
  • up_limit_id:记录 trx_list 列表中事务 ID 最小的 ID
  • low_limit_id:Read View 生成时刻系统尚未分配的下一个事务 ID

具体的比较规则如下:

  1. 首先比较 DB_TRX_ID < up_limit_id,如果小于,则当前事务能看到 DB_TRX_ID 所在的记录,如果大于等于进入下一个判断;
  2. 接下来判断 DB_TRX_ID >= low_limit_id,如果大于等于则代表 DB_TRX_ID 所在的记录在 Read View 生成后才出现的,那么对于当前事务肯定不可见,如果小于,则进入下一步判断
  3. 判断 DB_TRX_ID 是否在活跃事务中,如果在,则代表在 Read View 生成时刻,这个事务还是活跃状态,还没有 commit,修改的数据,当前事务也是看不到;如果不在,则说明这个事务在 Read View 生成之前就已经开始 commit,那么修改的结果是能够看见的。

MVCC的整体处理流程

假设有四个事务同时在执行,如下图所示:

事务1 事务2 事务3 事务4
事务开始 事务开始 事务开始 事务开始
…… …… …… 修改且已提交
进行中 快照读 进行中
…… …… ……  

从上述表格中,我们可以看到,当事务 2 对某行数据执行了快照读,数据库为该行数据生成一个 Read View 视图,可以看到事务 1 和事务 3 还在活跃状态,事务 4 在事务 2 快照读的前一刻提交了更新,所以,在 Read View 中记录了系统当前活跃事务 1,3,维护在一个列表中。同时可以看到 up_limit_id 的值为1,而 low_limit_id 为5,如下图所示:

在上述的例子中,只有事务4修改过该行记录,并在事务2进行快照读前,就提交了事务,所以该行当前数据的 undo log 如下所示:

当事务 2 在快照读该行记录的是,会拿着该行记录的 DB_TRX_ID 去跟 up_limit_id,lower_limit_id 和活跃事务列表进行比较,判读事务 2能看到该行记录的版本是哪个。

具体流程如下:

  1. 先拿该行记录的事务 4 去跟 Read View 中的 up_limit_id 相比较,判断是否小于,通过对比发现不小于,所以不符合条件;
  2. 继续判断事务 4 是否大于等于 low_limit_id,通过比较发现也不大于,所以不符合条件;
  3. 判断事务 4 是否处理 trx_list 列表中,发现不再次列表中,那么符合可见性条件,所以事务4修改后提交的最新结果对事务 2 的快照是可见的,因此,事务 2 读取到的最新数据记录是事务 4 所提交的版本,而事务 4 提交的版本也是全局角度的最新版本。

如下图所示:

RC、RR 级别下的 InnoDB 快照读有什么不同

因为 Read View 生成时机的不同,从而造成 RC、RR 级别下快照读的结果的不同:

  1. 在 RR 级别下的某个事务的对某条记录的第一次快照读会创建一个快照即 Read View,将当前系统活跃的其他事务记录起来,此后在调用快照读的时候,还是使用的是同一个 Read View,所以只要当前事务在其他事务提交更新之前使用过快照读,那么之后的快照读使用的都是同一个 Read View,所以对之后的修改不可见。
  2. 在 RR 级别下,快照读生成 Read View 时,Read View 会记录此时所有其他活动和事务的快照,这些事务的修改对于当前事务都是不可见的,而早于 Read View 创建的事务所做的修改均是可见。
  3. 在 RC 级别下,事务中,每次快照读都会新生成一个快照和 Read View,这就是我们在 RC 级别下的事务中可以看到别的事务提交的更新的原因。

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

延伸阅读
  1. MySQL 5.7 详细安装步骤
  2. Linux下MySQL的彻底卸载
  3. 一文读懂 MySQL 事务
  4. MySQL 怎么解决幻读问题
  5. MySQL join的使用和原理
发表评论