1MVCC

1.1基本概念

1). 当前读 读取的是记录的最新版本读取时还要保证其他并发事务不能修改当前记录会对读取的记录进行加 锁。对于我们日常的操作如select ... lock in share mode(共享锁)select ... for update、update、insert、delete(排他锁)都是一种当前读。 测试

在测试中我们可以看到即使是在默认的RR隔离级别下事务A中依然可以读取到事务B最新提交的内 容因为在查询语句后面加上了 lock in share mode 共享锁此时是当前读操作。当然当我们 加排他锁的时候也是当前读操作。

2). 快照读 简单的select不加锁就是快照读快照读读取的是记录数据的可见版本有可能是历史数据 不加锁是非阻塞读。 • Read Committed每次select都生成一个快照读。 • Repeatable Read开启事务后第一个select语句才是快照读的地方。 • Serializable快照读会退化为当前读。 测试:

在测试中,我们看到即使事务B提交了数据,事务A中也查询不到。 原因就是因为普通的select是快照 读而在当前默认的RR隔离级别下开启事务后第一个select语句才是快照读的地方后面执行相同 的select语句都是从快照中获取数据可能不是当前的最新数据这样也就保证了可重复读。

3). MVCC 全称 Multi-Version Concurrency Control多版本并发控制。指维护一个数据的多个版本 使得读写操作没有冲突快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现还需 要依赖于数据库记录中的三个隐式字段、undo log日志、readView。

接下来我们再来介绍一下InnoDB引擎的表中涉及到的隐藏字段 、undolog 以及 readview从 而来介绍一下MVCC的原理。

1.2隐藏字段

1.2.1介绍

当我们创建了上面的这张表我们在查看表结构的时候就可以显式的看到这三个字段。 实际上除了 这三个字段以外InnoDB还会自动的给我们添加三个隐藏字段及其含义分别是

而上述的前两个字段是肯定会添加的 是否添加最后一个字段DB_ROW_ID得看当前表有没有主键 如果有主键则不会添加该隐藏字段。

1.2.2测试

1). 查看有主键的表 stu 进入服务器中的 /var/lib/mysql/itcast/ , 查看stu的表结构信息, 通过如下指令:

ibd2sdi stu.ibd

查看到的表结构信息中有一栏 columns在其中我们会看到处理我们建表时指定的字段以外还有 额外的两个字段 分别是DB_TRX_ID 、 DB_ROLL_PTR 因为该表有主键所以没有DB_ROW_ID 隐藏字段。

2). 查看没有主键的表 employee 建表语句

 create table employee (id int , name varchar(10));

此时我们再通过以下指令来查看表结构及其其中的字段信息

ibd2sdi employee.ibd

查看到的表结构信息中有一栏 columns在其中我们会看到处理我们建表时指定的字段以外还有 额外的三个字段 分别是DB_TRX_ID 、 DB_ROLL_PTR 、DB_ROW_ID因为employee表是没有 指定主键的。

1.3undo log

1.3.1介绍

回滚日志在insert、update、delete的时候产生的便于数据回滚的日志。 当insert的时候产生的undo log日志只在回滚时需要在事务提交后可被立即删除。 而update、delete的时候产生的undo log日志不仅在回滚时需要在快照读时也需要不会立即 被删除。

1.3.2版本链

有一张表原始数据为

DB_TRX_ID : 代表最近修改事务ID记录插入这条记录或最后一次修改该记录的事务ID是
自增的。
DB_ROLL_PTR  由于这条数据是才插入的没有被更新过所以该字段值为null。

然后有四个并发事务同时在访问这张表。 A. 第一步

当事务2执行第一条修改语句时会记录undo log日志记录数据变更之前的样子; 然后更新记录 并且记录本次操作的事务ID回滚指针回滚指针用来指定如果发生回滚回滚到哪一个版本。

B.第二步

当事务3执行第一条修改语句时也会记录undo log日志记录数据变更之前的样子; 然后更新记 录并且记录本次操作的事务ID回滚指针回滚指针用来指定如果发生回滚回滚到哪一个版本。

C. 第三步

当事务4执行第一条修改语句时也会记录undo log日志记录数据变更之前的样子; 然后更新记 录并且记录本次操作的事务ID回滚指针回滚指针用来指定如果发生回滚回滚到哪一个版本。

最终我们发现不同事务或相同事务对同一条记录进行修改会导致该记录的undolog生成一条 记录版本链表链表的头部是最新的旧记录链表尾部是最早的旧记录。

1.4readview

ReadView读视图是 快照读 SQL执行时MVCC提取数据的依据记录并维护系统当前活跃的事务 未提交的id。 ReadView中包含了四个核心字段

而在readview中就规定了版本链数据的访问规则 trx_id 代表当前undolog版本链对应事务ID。

不同的隔离级别生成ReadView的时机不同 1READ COMMITTED 在事务中每一次执行快照读时生成ReadView。 2REPEATABLE READ仅在事务中第一次执行快照读时生成ReadView后续复用该ReadView。

1.5原理分析

1.5.1RC隔离级别

RC隔离级别下在事务中每一次执行快照读时生成ReadView。 我们就来分析事务5中两次快照读读取数据是如何获取数据的? 在事务5中查询了两次id为30的记录由于隔离级别为Read Committed所以每一次进行快照读 都会生成一个ReadView那么两次生成的ReadView如下。

那么这两次快照读在获取数据时就需要根据所生成的ReadView以及ReadView的版本链访问规则 到undolog版本链中匹配数据最终决定此次快照读返回的数据。 A. 先来看第一次快照读具体的读取过程

在进行匹配时会从undo log的版本链从上到下进行挨个匹配

• 先匹配

这条记录这条记录对应的 trx_id为4也就是将4带入右侧的匹配规则中。 ①不满足 ②不满足 ③不满足 ④也不满足 都不满足则继续匹配undo log版本链的下一条。

• 再匹配第二条

这条 记录对应的trx_id为3也就是将3带入右侧的匹配规则中。①不满足 ②不满足 ③不满足 ④也 不满足 都不满足则继续匹配undo log版本链的下一条。

• 再匹配第三条

录对应的trx_id为2也就是将2带入右侧的匹配规则中。①不满足 ②满足 终止匹配此次快照 读返回的数据就是版本链中记录的这条数据。

B. 再来看第二次快照读具体的读取过程:

在进行匹配时会从undo log的版本链从上到下进行挨个匹配

1.5.2RR隔离级别

RR隔离级别下仅在事务中第一次执行快照读时生成ReadView后续复用该ReadView。 而RR 是可 重复读在一个事务中执行两次相同的select语句查询到的结果是一样的。 那MySQL是如何做到可重复读的呢? 我们简单分析一下就知道了

我们看到在RR隔离级别下只是在事务中第一次快照读时生成ReadView后续都是复用该 ReadView那么既然ReadView都一样 ReadView的版本链匹配规则也一样 那么最终快照读返 回的结果也是一样的。

所以呢MVCC的实现原理就是通过 InnoDB表的隐藏字段、UndoLog 版本链、ReadView来实现的。 而MVCC + 锁则实现了事务的隔离性。 而一致性则是由redolog 与 undolog保证。