《Mysql是怎样运行的》补充

 19 第19章 从猫爷被杀说起-事务简介

19.1 事务的起源

19.1.1 原子性（Atomicity）

19.1.2 隔离性（Isolation）

其它的状态转换不会影响到本次状态转换，这个规则被称之为 隔离性

19.1.3 一致性（Consistency）

如果数据库中的数据全部符合现实世界中的约束（all defined rules），我们说这些数据就是一致的，或者说符合 一致性 的

如何保证数据库中数据的一致性？

数据库本身能为我们保证一部分一致性需求（就是数据库自身可以保证一部分现实世界的约束永远有效）。

我们知道 MySQL 数据库可以为表建立主键、唯一索引、外键、声明某个列为 NOT NULL 来拒绝 NULL 值的插入。比如说当我们对某个列建立唯一索引时，如果插入某条记录时该列的值重复了，那么 MySQL 就会报错并且拒绝插入

更多的一致性需求需要靠写业务代码的程序员自己保证

每一笔交易完成后，都需要保证整个系统的余额等于所有账户的收入减去所有账户的支出

19.1.4 持久性（Durability）

当现实世界的一个状态转换完成后，这个转换的结果将永久的保留，这个规则被设计数据库的大叔们称为 持久性 。

19.2 事务的概念

事务 大致上划分成了这么几个状态：

活动的（active）

事务对应的数据库操作正在执行过程中时，我们就说该事务处在 活动的 状态。

部分提交的（partially committed）

当事务中的最后一个操作执行完成，但由于操作都在内存中执行，所造成的影响并没有刷新到磁盘时，我们就说该事务处在 部分提交的 状态。

失败的（failed）

当事务处在 活动的 或者 部分提交的 状态时，可能遇到了某些错误（数据库自身的错误、操作系统错误或者直接断电等）而无法继续执行，或者人为的停止当前事务的执行，我们就说该事务处在 失败的 状态。

中止的（aborted）

如果事务执行了半截而变为 失败的 状态，比如我们前边唠叨的狗哥向猫爷转账的事务，当狗哥账户的钱被扣除，但是猫爷账户的钱没有增加时遇到了错误，从而当前事务处在了 失败的 状态，那么就需要把已经修改的狗哥账户余额调整为未转账之前的金额，换句话说，就是要撤销失败事务对当前数据库造成的影响。书面一点的话，我们把这个撤销的过程称之为 回滚 。当 回滚 操作执行完毕时，也就是数据库恢复到了执行事务之前的状态，我们就说该事务处在了 中止的 状态。

提交的（committed）

当一个处在 部分提交的 状态的事务将修改过的数据都同步到磁盘上之后，我们就可以说该事务处在了 提交的 状态。

19.3 MySQL中事务的语法

19.3.1 开启事务

BEGIN [WORK];

START TRANSACTION;

READ ONLY

READ WRITE

WITH CONSISTENT SNAPSHOT

如果我们不显式指定事务的访问模式，那么该事务的访问模式就是 读写 模式

19.3.2 提交事务

COMMIT [WORK]

19.3.3 手动中止事务

ROLLBACK [WORK]

19.3.4 支持事务的存储引擎

MySQL 中并不是所有存储引擎都支持事务的功能，目前只有 InnoDB 和 NDB 存储引擎支持

19.3.5 自动提交

MySQL 中有一个系统变量 autocommit

19.3.6 隐式提交

定义或修改数据库对象的数据定义语言（ Data definition language ，缩写为： DDL ）。

所谓的数据库对象，指的就是 数据库 、 表 、 视图 、 存储过程 等等这些东西。当我们使用 CREATE 、ALTER 、 DROP 等语句去修改这些所谓的数据库对象时，就会隐式的提交前边语句所属于的事务

隐式使用或修改 mysql 数据库中的表 当我们使用 ALTER USER 、 CREATE USER 、 DROP USER 、 GRANT 、 RENAME USER 、 REVOKE 、 SETPASSWORD 等语句时也会隐式的提交前边语句所属于的事务

事务控制或关于锁定的语句

当我们在一个事务还没提交或者回滚时就又使用 START TRANSACTION 或者 BEGIN 语句开启了另一个事务时，会隐式的提交上一个事务

加载数据的语句

比如我们使用 LOAD DATA 语句来批量往数据库中导入数据时，也会隐式的提交前边语句所属的事务

关于 MySQL 复制的一些语句

使用 START SLAVE 、 STOP SLAVE 、 RESET SLAVE 、 CHANGE MASTER TO 等语句时也会隐式的提交前边语句所属的事务。

其它的一些语句

使用 ANALYZE TABLE 、 CACHE INDEX 、 CHECK TABLE 、 FLUSH 、 LOAD INDEX INTO CACHE 、 OPTIMIZETABLE 、 REPAIR TABLE 、 RESET 等语句也会隐式的提交前边语句所属的事务

19.3.7 保存点

SAVEPOINT 保存点名称;

当我们想回滚到某个保存点时，可以使用下边这个语句（下边语句中的单词 WORK 和 SAVEPOINT 是可有可无的）：

ROLLBACK [WORK] TO [SAVEPOINT] 保存点名称

20 第 20 章 说过的话就一定要办到 -redo 日志（上）

20.2 redo 日志是个啥

redo 日志占用的空间非常小

存储表空间 ID 、页号、偏移量以及需要更新的值所需的存储空间是很小的，关于 redo 日志的格式我们稍后会详细唠叨，现在只要知道一条 redo 日志占用的空间不是很大就好了。

redo 日志是顺序写入磁盘的

在执行事务的过程中，每执行一条语句，就可能产生若干条 redo 日志，这些日志是按照产生的顺序写入磁盘的，也就是使用顺序IO

20.3 redo 日志格式

redo 日志本质上只是 记录了一下事务对数据库做了哪些修改

20.3.1 简单的 redo 日志类型

记录一下在某个页面的某个偏移量处修改了几个字节的值，具体被修改的内容是啥就好了

20.3.2 复杂一些的 redo 日志类型

把一条记录插入到一个页面时需要更改的地方非常多

物理层面看，这些日志都指明了对哪个表空间的哪个页进行了修改。

逻辑层面看，在系统奔溃重启时，并不能直接根据这些日志里的记载，将页面内的某个偏移量处恢复成某个数据，而是需要调用一些事先准备好的函数，执行完这些函数后才可以将页面恢复成系统奔溃前的样子。

20.3.3 redo 日志格式小结

redo 日志会把事务在执行过程中对数据库所做的所有修改都记录下来，在之后系统奔溃重启后可以把事务所做的任何修改都恢复出来

20.4 Mini-Transaction

20.4.1 以组的形式写入 redo 日志

20.4.2 Mini-Transaction 的概念

把对底层页面中的一次原子访问的过程称之为一个 Mini-Transaction ，简称 mtr ，比如上边

所说的修改一次 Max Row ID 的值算是一个 Mini-Transaction ，向某个索引对应的 B+ 树中插入一条记录的过程也算是一个 Mini-Transaction 。通过上边的叙述我们也知道，一个所谓的 mtr 可以包含一组 redo 日志，在进行奔溃恢复时这一组 redo 日志作为一个不可分割的整体

20.5 redo 日志的写入过程

20.5.1 redo log block

20.5.2 redo 日志缓冲区

写入 redo 日志时也不能直接直接写到磁盘上，实际上在服务器启动时就向操作系统申请了一大片称之为 redo log buffer 的连续内存空间，翻译成中文就是 redo日志缓冲区 ，我们也可以简称为 log buffer

20.5.3 redo 日志写入 log buffer

向 log buffer 中写入 redo 日志的过程是顺序的，也就是先往前边的 block 中写，当该 block 的空闲空间用完之后再往下一个block 中写

21 第 21 章 说过的话就一定要办到 -redo 日志（下）

21.1 redo 日志文件

21.1.1 redo 日志刷盘时机

log buffer 空间不足时

事务提交时

后台线程不停的刷刷刷

正常关闭服务器时

做所谓的 checkpoint 时（我们现在没介绍过 checkpoint 的概念，稍后会仔细唠叨，稍安勿躁）

其他的一些情况

21.1.2 redo 日志文件组

这些文件以 ib_logfile[数字] （ 数字 可以是 0 、 1 、 2 ... ）的形式进行命名

21.1.3 redo 日志文件格式

log buffer 本质上是一片连续的内存空间，被划分成了若干个 512 字节大小的 block 。 将 log

buffer 中的 redo 日志刷新到磁盘的本质就是把 block 的镜像写入日志文件中

21.2 Log Sequeue Number

为记录已经写入的 redo 日志量，设计了一个称之为 Log Sequeue Number 的全局变量，翻译过来就是： 日志序列号 ，简称 lsn

每一组由 mtr 生成的 redo 日志都有一个唯一的 LSN 值与其对应， LSN 值越小，说明redo日志产生的越早

21.2.1 flushed_to_disk_lsn

当有新的 redo 日志写入到 log buffer 时，首先 lsn 的值会增长，但 flushed_to_disk_lsn 不变，

随后随着不断有 log buffer 中的日志被刷新到磁盘上， flushed_to_disk_lsn 的值也跟着增长。 如果两者的值相同时，说明log buffer 中的所有 redo 日志都已经刷新到磁盘中了

21.2.2 lsn 值和 redo 日志文件偏移量的对应关系

21.2.3 flush 链表中的 LSN

我们知道一个 mtr 代表一次对底层页面的原子访问，在访问过程中可能会产生一组不可分割的 redo 日志，在mtr 结束时，会把这一组 redo 日志写入到 log buffer 中。除此之外，在 mtr 结束时还有一件非常重要的事情要做，就是 把在 mtr 执行过程中可能修改过的页面加入到 Buffer Pool 的 flush 链表

flush 链表中的脏页是按照页面的第一次修改时间从大到小进行排序的

flush 链表中的脏页按照修改发生的时间顺序进行排序，也就是按照oldest_modification代表的 LSN 值进行排序，被多次更新的页面不会重复插入到 flush 链表中，但是会更新newest_modification属性的值

21.3 checkpoint

redo 日志只是为了系统奔溃后恢复脏页用的，如果对应的脏页已经刷新到了磁盘，也就是说即使现在系统奔溃，那么在重启后也用不着使用redo 日志恢复该页面了，所以该 redo 日志也就没有存在的必要了，那么它占用的磁盘空间就可以被后续的redo日志所重用 。也就是说： 判断某些 redo 日志占用的磁盘空间是否可以覆盖的依据就是它对应的脏页是否已经刷新到磁盘里

凡是在系统 lsn 值小于该节点的 oldest_modification 值时产生的 redo 日志都是可以被覆盖掉的

上述关于 checkpoint 的信息只会被写到日志文件组的第一个日志文件的管理信息中

21.3.1 批量从 flush 链表中刷出脏页

21.3.2 查看系统中的各种 LSN 值

21.4 innodb_flush_log_at_trx_commit 的用法

如果有的同学对事务的 持久性 要求不是那么强烈的话，可以选择修改一个称为 innodb_flush_log_at_trx_commit 的系统变量的值

21.5 崩溃恢复

21.5.1 确定恢复的起点

最近发生的那次 checkpoint 的信息

21.5.2 确定恢复的终点

21.5.3 怎么恢复

使用哈希表 根据 redo 日志的 space ID 和 page number 属性计算出散列值，把 space ID 和 page number 相同的 redo日志放到哈希表的同一个槽里

跳过已经刷新到磁盘的页面

21.6 遗漏的问题： LOG_BLOCK_HDR_NO 是如何计算的

22 第 22 章 后悔了怎么办 -undo 日志（上）

22.1 事务回滚的需求

22.2 事务 id

22.2.1 给事务分配 id 的时机

22.2.2 事务 id 是怎么生成的

22.2.3 trx_id 隐藏列

聚簇索引的记录除了会保存完整的用户数据以外，而且还会自动添加名为trx_id 、 roll_pointer 的隐藏列，如果用户没有在表中定义主键以及 UNIQUE 键，还会自动添加一个名为row_id 的隐藏列

22.3 undo 日志的格式

22.3.1 INSERT 操作对应的 undo 日志

22.3.1.1 roll pointer 隐藏列的含义

roll_pointer 本质就是一个指针，指向记录对应的 undo 日志

22.3.2 DELETE 操作对应的 undo 日志

阶段一：仅仅将记录的 delete_mask 标识位设置为 1 ，其他的不做修改（其实会修改记录的 trx_id 、roll_pointer 这些隐藏列的值）。设计 InnoDB 的大叔把这个阶段称之为 delete mark

阶段二： 当该删除语句所在的事务提交之后 ，会有 专门的线程后 来真正的把记录删除掉。所谓真正的删除就是把该记录从 正常记录链表 中移除，并且加入到 垃圾链表 中，然后还要调整一些页面的其他信息，比如页面中的用户记录数量 PAGE_N_RECS 、上次插入记录的位置 PAGE_LAST_INSERT 、垃圾链表头节点的指针PAGE_FREE 、页面中可重用的字节数量 PAGE_GARBAGE 、还有页目录的一些信息等等。设计 InnoDB 的大叔把这个阶段称之为 purge

22.3.3 UPDATE 操作对应的 undo 日志

在执行 UPDATE 语句时， InnoDB 对更新主键和不更新主键这两种情况有截然不同的处理方案

22.3.3.1 不更新主键的情况

就地更新（ in-place update ）

先删除掉旧记录，再插入新记录

22.3.3.2 更新主键的情况

将旧记录进行 delete mark 操作

高能注意： 这里是 delete mark 操作！这里是 delete mark 操作！这里是 delete mark 操作！ 也就是说在 UPDATE语句所在的事务提交前，对旧记录只做一个 delete mark 操作，在事务提交后才由 专门的线程做 purge 操作，把它加入到垃圾链表中

根据更新后各列的值创建一条新记录，并将其插入到聚簇索引中（需重新定位插入的位置）。

由于更新后的记录主键值发生了改变，所以需要重新从聚簇索引中定位这条记录所在的位置，然后把它插进去

23 第 23 章 后悔了怎么办 -undo 日志（下）

23.1 通用链表结构

23.2 FIL_PAGE_UNDO_LOG 页面

23.3 Undo 页面链表

23.3.1 单个事务中的 Undo 页面链表

按需分配，啥时候需要啥时候再分配，不需要就不分配

23.3.2 多个事务中的 Undo 页面链表

为了尽可能提高 undo日志 的写入效率， 不同事务执行过程中产生的 undo 日志需要被写入到不同的 Undo 页面链表中

23.4 undo 日志具体写入过程

23.4.1 段（ Segment ）的概念

23.4.2 Undo Log Segment Header

23.4.3 Undo Log Header

23.4.4 小结

23.5 重用 Undo 页面

23.6 回滚段

23.6.1 回滚段的概念

23.6.2 从回滚段中申请 Undo 页面链表

23.6.3 多个回滚段

一个事务执行过程中最多分配 4 个 Undo页面 链表，而一个回滚段里只有 1024 个 undo slot ，很显然undo slot 的数量有点少啊。我们即使假设一个读写事务执行过程中只分配 1 个 Undo页面 链表，那 1024 个undo slot 也只能支持 1024 个读写事务同时执行

不同的回滚段可能分布在不同的表空间中

23.6.4 回滚段的分类

在修改针对普通表的回滚段中的 Undo 页面时，需要记录对应的 redo 日志，而修改针对临时表的回滚段中的Undo 页面时，不需要记录对应的 redo 日志

23.6.5 为事务分配 Undo 页面链表详细过程

如果一个事务在执行过程中既对普通表的记录做了改动，又对临时表的记录做了改动，那么需要为这个记录分配2 个回滚段。并发执行的不同事务其实也可以被分配相同的回滚段，只要分配不同的undo slot 就可以了

23.7 回滚段相关配置

23.7.1 配置回滚段数量

23.7.2 配置 undo 表空间

24 第 24 章 一条记录的多幅面孔 - 事务的隔离级别与 MVCC

24.1 事前准备

mysql> SELECT * FROM hero;

+--------+--------+---------+

| number | name | country |

+--------+--------+---------+

| 1 | 刘备 | 蜀 |

+--------+--------+---------+

1 row in set (0.00 sec)

24.2 事务隔离级别

24.2.1 事务并发执行遇到的问题

脏写（ Dirty Write ）

脏读（ Dirty Read ）

不可重复读（ Non-Repeatable Read ）

如果 一个事务只能读到另一个已经提交的事务修改过的数据，并且其他事务每对该数据进行一次修改并提交后，该事务都能查询得到最新值 ，那就意味着发生了 不可重复读

幻读（ Phantom ）

幻读 强调的是一个事务按照某个相同条件多次读取记录时，后读取时读到了之前没有读到的记录

24.2.2 SQL 标准中的四种隔离级别

READ UNCOMMITTED ：未提交读。

READ COMMITTED ：已提交读。

REPEATABLE READ ：可重复读。

SERIALIZABLE ：可串行化

24.2.3 MySQL 中支持的四种隔离级别

Oracle 就只支持 READ COMMITTED 和SERIALIZABLE 隔离级别

MySQL 在 REPEATABLE READ 隔离级别下，是可以禁止幻读问题的发生的

24.2.3.1 如何设置事务的隔离级别

使用 GLOBAL 关键字（在全局范围影响）

使用 SESSION 关键字（在会话范围影响）

上述两个关键字都不用（只对执行语句后的下一个事务产生影响）

24.3 MVCC 原理

24.3.1 版本链

InnoDB使用锁来保证不会有脏写情况的发生，也就是在第一个事务更新了某条记录后，就会给这条记录加锁，另一个事务再次更新时就需要等待第一个事务提交了，把锁释放之后才可以继续更新

所有的版本都会被 roll_pointer 属性连接成一个链表，我们把这个链表称之为 版本链 ， 版本链的头节点就是当前记录最新的值

24.3.2 ReadView 

对于使用 READ COMMITTED 和 REPEATABLE READ 隔离级别的事务来说，都必须保证读到已经提交了的事务修改过的记录，也就是说假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的，核心问题就是： 需要判断一下版本链中的哪个版本是当前事务可见的

MySQL 中， READ COMMITTED 和 REPEATABLE READ 隔离级别的的一个非常大的区别就是 它们生成 ReadView 的时机不同

24.3.2.1 READ COMMITTED —— 每次读取数据前都生成一个 ReadView

使用READ COMMITTED 隔离级别的事务在每次查询开始时都会生成一个独立的 ReadView

24.3.2.2 REPEATABLE READ —— 在第一次读取数据时生成一个 ReadView

只会在第一次执行查询语句时生成一个 ReadView ，之后的查询就不会重复生成了

也就是说两次 SELECT 查询得到的结果是重复的

24.3.3 MVCC 小结

从上边的描述中我们可以看出来，所谓的 MVCC （ Multi-Version Concurrency Control ，多版本并发控制）指的就是在使用 READ COMMITTD 、 REPEATABLE READ 这两种隔离级别的事务在执行普通的 SEELCT 操作时访问记录的版本链的过程，这样子可以使不同事务的 读-写 、 写-读 操作并发执行，从而提升系统性能。 READ COMMITTD 、REPEATABLE READ 这两个隔离级别的一个很大不同就是： 生成 ReadView 的时机不同， READ COMMITTD 在每一次进行普通SELECT 操作前都会生成一个 ReadView ，而 REPEATABLE READ 只在第一次进行普通 SELECT 操作前生成一个ReadView ，之后的查询操作都重复使用这个 ReadView 就好了

说执行DELETE语句或者更新主键的UPDATE语句并不会立即把对应的记录完全从页面中删除，而

是执行一个所谓的delete mark操作，相当于只是对记录打上了一个删除标志位，这主要就是为MVCC服务的

24.4 关于 purge

25 第 25 章 工作面试老大难 - 锁

25.1 解决并发事务带来问题的两种基本方式

并发事务访问相同记录的情况大致可以划分为 3 种

读-读 情况：即并发事务相继读取相同的记录。

读取操作本身不会对记录有一毛钱影响，并不会引起什么问题，所以允许这种情况的发生。

写-写 情况：即并发事务相继对相同的记录做出改动。

我们前边说过，在这种情况下会发生 脏写 的问题，任何一种隔离级别都不允许这种问题的发生。所以在多个未提交事务相继对一条记录做改动时，需要让它们排队执行，这个排队的过程其实是通过 锁 来实现的。这个所谓的 锁 其实是一个内存中的结构，在事务执行前本来是没有锁的。

当一个事务想对这条记录做改动时，首先会看看内存中有没有与这条记录关联的 锁结构 ，当没有的时候就会在内存中生成一个 锁结构 与之关联

方案一：读操作利用多版本并发控制（ MVCC ），写操作进行 加锁

方案二：读、写操作都采用 加锁 的方式

25.1.1 一致性读（ Consistent Reads ）

事务利用 MVCC 进行的读取操作称之为 一致性读 ，或者 一致性无锁读 ，有的地方也称之为 快照读

25.1.2 锁定读（ Locking Reads ）

25.1.2.1 共享锁和独占锁

25.1.2.2 锁定读的语句

对读取的记录加 S锁 ：

SELECT ... LOCK IN SHARE MODE;

对读取的记录加 X锁 ：

SELECT ... FOR UPDATE;

25.1.3 写操作

25.2 多粒度锁

前边提到的 锁 都是针对记录的，也可以被称之为 行级锁 或者 行锁 ，对一条记录加锁影响的也只是这条记录而已，我们就说这个锁的粒度比较细；其实一个事务也可以在 表 级别进行加锁，自然就被称之为 表级锁 或者 表锁

意向共享锁，英文名： Intention Shared Lock ，简称 IS锁 。当事务准备在某条记录上加 S锁 时，需要先在表级别加一个 IS锁 。 意向独占锁，英文名： Intention Exclusive Lock ，简称 IX锁 。当事务准备在某条记录上加 X锁 时，需要先在表级别加一个 IX锁

IS 、 IX 锁是表级锁，它们的提出仅仅为了在之后加表级别的 S 锁和 X 锁时可以快速判断表中的记录是否被上锁，以避免用遍历的方式来查看表中有没有上锁的记录，也就是说其实IS 锁和 IX 锁是兼容的， IX 锁和 IX 锁是兼容的

25.3 MySQL 中的行锁和表锁

25.3.1 其他存储引擎中的锁

25.3.2 InnoDB 存储引擎中的锁

InnoDB 存储引擎既支持表锁，也支持行锁。表锁实现简单，占用资源较少，不过粒度很粗，有时候你仅仅需要锁住几条记录，但使用表锁的话相当于为表中的所有记录都加锁，所以性能比较差。行锁粒度更细，可以实现更精准的并发控制

25.3.2.1 InnoDB 中的表级锁

手动获取 InnoDB 存储引擎提供的表 t 的 S锁 或者 X锁 可以这么写：

LOCK TABLES t READ ： InnoDB 存储引擎会对表 t 加表级别的 S锁 。

LOCK TABLES t WRITE ： InnoDB 存储引擎会对表 t 加表级别的 X锁 。

InnoDB 的厉害之处还是实现了更细粒度的行锁

动给 AUTO_INCREMENT 修饰的列递增赋值的原理主要是两个

采用 AUTO-INC 锁

采用一个轻量级的锁

25.3.2.2 InnoDB 中的行级锁

Record Locks ：

Gap Locks ： 仅仅是为了防止插入幻影记录而提出的

25.3.3 InnoDB 锁的内存结构

26 第 26 章 写作本书时用到的一些重要的参考资料

26.1 感谢

26.1.1 一些链接

26.1.2 一些书籍