目录
1 页的类型
页是InnoDB存储引擎管理数据的基本单位,一个页的大小一般是 16KB 。InnoDB 为了不同的目的而设计了许多种不同类型的 页 ,比如存放表空间头部信息的页,存放 Insert Buffer 信息的页,存放 INODE 信息的页,存放 undo 日志信息的页等等
本篇文章聚焦的是那些存放我们表中记录的那种类型的页,官方称这种存放记录的页为索引( INDEX )页,而这些表中的记录就是我们日常口中所称的数据 ,所以也可以叫这种存放记录的页为数据页。
2 数据页的结构(快速浏览)
一个数据页的结构大致如下图所示:(图片非原创,侵权立删)
下边我们用表格的方式来大致描述一下这7个部分都存储一些啥内容:
3 记录(数据)在页中的存储
在页的7个组成部分中,我们自己存储的记录会按照我们指定的行格式 存储到 User Records 部分。但是在一开 始生成页的时候,其实并没有 User Records 这个部分,每当我们插入一条记录,都会从 Free Space 部分,也就 是尚未使用的存储空间中申请一个记录大小的空间划分到 User Records 部分,当 Free Space 部分的空间全部 被 User Records 部分替代掉之后,也就意味着这个页使用完了,如果还有新的记录插入的话,就需要去申请新 的页了,这个过程的图示如下:
3.1 记录头信息的奥秘
先创建一个表:
mysql> CREATE TABLE page_demo(
-> c1 INT,
-> c2 INT,
-> c3 VARCHAR(10000),
-> PRIMARY KEY (c1)
-> ) CHARSET=ascii ROW_FORMAT=Compact;
Query OK, 0 rows affected (0.03 sec)
这个新创建的 page_demo 表有3个列,其中 c1 和 c2 列是用来存储整数的, c3 列是用来存储字符串的。需要注意的是,我们把 c1 列指定为主键,所以在具体的行格式中InnoDB就没必要为我们去创建那个所谓的 row_id 隐 藏列了。而且我们为这个表指定了 ascii 字符集以及 Compact 的行格式。所以这个表中记录的行格式示意图就是 这样的:
我们再次先把这些记录头信息 中各个属性的大体意思浏览一下(我们目前使用 Compact 行格式进行演示):
为了方便讲解记录头信息中的内容,我们把上面表中记录的行格式图简化一下(不代表其他本该有的信息不存在哈)
下边我们试着向 page_demo 表中插入几条记录:
mysql> INSERT INTO page_demo VALUES(1, 100, 'aaaa'), (2, 200, 'bbbb'), (3, 300, 'cccc'), (4, 400, 'dddd');
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0
所以这些记录的示意图大致如下:
看这个图的时候需要注意一下,各条记录在 User Records 中存储的时候并没有空隙,这里只是为了大家观看方 便才把每条记录单独画在一行中。我们对照着这个图来看看记录头信息中的各个属性是啥意思:
- delete_mask
这个属性标记着当前记录是否被删除,占用1个二进制位,值为0的时候代表记录并没有被删除,为 1 的时候代表记录被删除掉了。
被删除的记录还在页中么?
是的,摆在台面上的和背地里做的可能大相径庭,你以为它删除了,可它还在真实的磁盘上
这些被删除的记录之所以不立即从磁盘上移除,是因为移除它们之后把其他的记录在磁盘上重新排列需要性能消耗,所以只是打一个删除标记而已,所有被删除掉的记录都会组成一个所谓的垃圾链表,在这个链表中的记录占用的空间称之为所谓的 可重用空间,之后如果有新记录插入到表中的话,可能把这些被删除的记录占用的存储空间覆盖掉。
tips:将这个delete_mask位设置为1和将被删除的记录加入到垃圾链表中其实是两个阶段
这部分内容是事务的内容,以后写到那里了会提到
- min_rec_mask
B+树的每层非叶子节点中的最小记录都会添加该标记,什么是个 B+ 树?什么是个非叶子节点?好吧,等会 再聊这个问题。反正我们自己插入的四条记录的 min_rec_mask 值都是 0 ,意味着它们都不是 B+ 树的非叶 子节点中的最小记录。
- n_owned
这个暂时保密,稍后会详细讲解这一部分
- heap_no
这个属性表示当前记录在本页中的位置,从图中可以看出来,我们插入的4条记录在本页中的位置分别 是: 2 、 3 、 4 、 5 。是不是少了点啥?是的,怎么不见 heap_no 值为 0 和 1 的记录呢?
这其实是设计 InnoDB 的大叔们玩的一个小把戏,他们自动给每个页里边儿加了两个记录,由于这两个记录 并不是我们自己插入的,所以有时候也称为 伪记录 或者 虚拟记录 。这两个伪记录一个代表 最小记录 ,一 个代表 最大记录 ,等一下哈~,记录可以比大小么?
是的,记录也可以比大小,对于一条完整的记录来说,比较记录的大小就是比较 主键 的大小。比方说我们 插入的4行记录的主键值分别是: 1 、 2 、 3 、 4 ,这也就意味着这4条记录的大小从小到大依次递增。
但是不管我们向页中插入了多少自己的记录,设计 InnoDB 的大叔们都规定他们定义的两条伪记录分别为最 小记录与最大记录。这两条记录的构造十分简单,都是由5字节大小的记录头信息和8字节大小的一个固定 的部分组成的,如图所示:
由于这两条记录不是我们自己定义的记录,所以它们并不存放在 页 的 User Records 部分,他们被单独放在 一个称为 Infimum + Supremum 的部分,如图所示:
- record_type
这个属性表示当前记录的类型,一共有4种类型的记录,
0 表示普通记录,
1 表示B+树非叶节点记录,
2 表 示最小记录,
3 表示最大记录。
从图中我们也可以看出来,我们自己插入的记录就是普通记录,它们的 record_type 值都是 0 ,而最小记录和最大记录的 record_type 值分别为 2 和 3 。
至于 record_type 为 1 的情况,我们之后在说索引的时候会重点强调的
- next_record
这玩意儿非常重要,它表示从当前记录的真实数据到下一条记录的真实数据的地址偏移量。比方说第一条记 录的 next_record 值为 32 ,意味着从第一条记录的真实数据的地址处向后找 32 个字节便是下一条记录的 真实数据。如果你熟悉数据结构的话,就立即明白了,这其实是个 链表 ,可以通过一条记录找到它的下一 条记录。但是需要注意注意再注意的一点是, 下一条记录 指的并不是按照我们插入顺序的下一条记录,而 是按照主键值由小到大的顺序的下一条记录。而且规定 Infimum记录(也就是最小记录) 的下一条记录就是 本页中主键值最小的用户记录,而本页中主键值最大的用户记录的下一条记录就是 Supremum记录(也就 是最大记录) ,为了更形象的表示一下这个 next_record 起到的作用,我们用箭头来替代一下 next_record 中的地址偏移量:
从图中可以看出来,我们的记录按照主键从小到大的顺序形成了一个单链表。 最大记录 的 next_record 的 值为 0 ,这也就是说最大记录是没有 下一条记录 了,它是这个单链表中的最后一个节点。如果从中删除掉 一条记录,这个链表也是会跟着变化的,比如我们把第2条记录删掉:
mysql> DELETE FROM page_demo WHERE c1 = 2;
Query OK, 1 row affected (0.02 sec)
删掉第2条记录后的示意图就是:(注意观察delete_mask)
从图中可以看出来,删除第2条记录前后主要发生了这些变化:
第2条记录并没有从存储空间中移除,而是把该条记录的 delete_mask 值设置为 1 。
第2条记录的 next_record 值变为了0,意味着该记录没有下一条记录了。
第1条记录的 next_record 指向了第3条记录。
还有一点你可能忽略了,就是最大记录 的 n_owned 值从 5 变成了 4 ,关于这一点的变化我们稍后会详细说明的。
所以,不论我们怎么对页中的记录做增删改操作,InnoDB始终会维护一条记录的单链表,链表中的各个节点是按照主键值由小到大的顺序连接起来的。
此时,(因为刚刚我们把第二条记录删除了)再把第二条记录插入回去,会发生什么事情?
mysql> INSERT INTO page_demo VALUES(2, 200, 'bbbb');
Query OK, 1 row affected (0.00 sec)
从图中可以看到, InnoDB 并没有因为新记录的插入而为它申请新的存储空间,而是直接复用了原来被删除记录的存储空间。
tips:当数据页中存在多条被删除掉的记录时,
这些记录的next_record属性将会把这些被删除掉的记录组成一个垃圾链表,
以备之后重用这部分存储空间
4 PageDirectory(页目录)
现在我们了解了记录在页中按照主键值由小到大顺序串联成一个单链表,那如果我们想根据主键值查找页中的某条记录该咋办呢?
最笨的办法:从 Infimum 记录(最小记录)开始,沿着链表一直往后找,总有一天会找到
这种方法在数据量小的时候还可以用一下,但是实际场景下,业务量大数据量大,这样的方法是不可行的,我们主打一个能省就省的原则
设计 InnoDB 的大叔们设计了一种更6的查找方式,他们从书的目录中找到了灵感
我们平常想从一本书中查找某个内容的时候,一般会先看目录,找到需要查找的内容对应的书的页码,然后到对 应的页码查看内容。设计 InnoDB 的大叔们为我们的记录也制作了一个类似的目录,他们的制作过程是这样的:
1. 将所有正常的记录(包括最大和最小记录,不包括标记为已删除的记录)划分为几个组。
2. 每个组的最后一条记录(也就是组内最大的那条记录)的头信息中的 n_owned 属性表示该记录拥有多少条记录,也就是该组内共有几条记录。
3. 将每个组的最后一条记录的地址偏移量单独提取出来按顺序存储到靠近页的尾部的地方,这个地方就是所谓的 Page Directory ,也就是 页目录 (此时应该返回头看看页面各个部分的图,多看看加深印象)。页面目录中的这些地址偏移量被称为槽 (英文名: Slot ),所以这个页面目录就是由槽组成的。
比方说现在的 page_demo 表中正常的记录共有6条, InnoDB 会把它们分成两组,第一组中只有一个最小记录, 第二组中是剩余的5条记录,看下边的示意图:
从这个图中我们需要注意这么几点:
- 现在 页目录部分中有两个槽,也就意味着我们的记录被分成了两个组, 槽1中的值是 112 ,代表最大记录的地址偏移量(就是从页面的0字节开始数,数112个字节);槽0中的值是 99 ,代表最小记录的地址偏移量。
- 注意最小和最大记录的头信息中的 n_owned 属性
最小记录的 n_owned 值为 1 ,这就代表着以最小记录结尾的这个分组中只有 1 条记录,也就是最小记录本身。
最大记录的 n_owned 值为 5 ,这就代表着以最大记录结尾的这个分组中只有 5 条记录,包括最大记录本 身还有我们自己插入的 4 条记录。
99 和 112 这样的地址偏移量很不直观,我们用箭头指向的方式替代数字,这样更易于我们理解,所以修改后的 示意图就是这样:
为什么最小记录的 n_owned 值为1,而最大记录的n_owned 值为 5 呢,这里头有什么猫腻么?
是的,设计 InnoDB 的大叔们对每个分组中的记录条数是有规定的:对于最小记录所在的分组只能有 1 条记录, 最大记录所在的分组拥有的记录条数只能在 1~8 条之间,剩下的分组中记录的条数范围只能在是 4~8 条之间。 所以分组是按照下边的步骤进行的:
- 初始情况下一个数据页里只有最小记录和最大记录两条记录,它们分属于两个分组。
- 之后每插入一条记录,都会从 页目录 中找到主键值比本记录的主键值大并且差值最小的槽,然后把该槽对 应的记录的 n_owned 值加1,表示本组内又添加了一条记录,直到该组中的记录数等于8个。
- 在一个组中的记录数等于8个后再插入一条记录时,会将组中的记录拆分成两个组,一个组中4条记录,另一 个5条记录。这个过程会在 页目录 中新增一个槽来记录这个新增分组中最大的那条记录的偏移量。
为了展示的更加直观,我们再往表里面插入十几条数据(过程不再演示)
现在看怎么从这个页目录中查找记录。因为各个槽代表的记录的主键值都是从小到大排序的,所以我们可以使用所谓的二分法 来进行 快速查找。4个槽的编号分别是: 0 、 1 、 2 、 3 、 4 ,所以初始情况下最低的槽就是 low=0 ,最高的槽就是 high=4 。比方说我们想找主键值为 6 的记录,过程是这样的:
1. 计算中间槽的位置: (0+4)/2=2 ,所以查看槽2对应记录的主键值为 8 ,又因为 8 > 6 ,所以设置 high=2 , low 保持不变。
2. 重新计算中间槽的位置: (0+2)/2=1 ,所以查看 槽1 对应的主键值为 4 ,又因为 4 < 6 ,所以设置 low=1 , high 保持不变。
3. 因为 high - low 的值为1,所以确定主键值为 5 的记录在槽2对应的组中。此刻我们需要找到槽2中主键 值最小的那条记录,然后沿着单向链表遍历 槽2 中的记录。但是我们前边又说过,每个槽对应的记录都是该 组中主键值最大的记录,这里 槽2 对应的记录是主键值为 8 的记录,怎么定位一个组中最小的记录呢?别忘 了各个槽都是挨着的,我们可以很轻易的拿到 槽1 对应的记录(主键值为 4 ),该条记录的下一条记录就 是 槽2 中主键值最小的记录,该记录的主键值为 5 。所以我们可以从这条主键值为 5 的记录出发,遍历 槽 2 中的各条记录,直到找到主键值为 6 的那条记录即可。由于一个组中包含的记录条数只能是1~8条,所以 遍历一个组中的记录的代价是很小的。
所以在一个数据页中查找指定主键值的记录的过程分为两步:
1. 通过二分法确定该记录所在的槽,并找到该槽中主键值最小的那条记录。
2. 通过记录的 next_record 属性遍历该槽所在的组中的各个记录。
5 Page Header(页面头部)
设计 InnoDB 的大叔们为了能得到一个数据页中存储的记录的状态信息,比如本页中已经存储了多少条记录,第 一条记录的地址是什么,页目录中存储了多少个槽等等,特意在页中定义了一个叫 Page Header 的部分,它是 页 结构的第二部分,这个部分占用固定的 56 个字节,专门存储各种状态信息,具体各个字节的作用看下表:
(从 PAGE_N_DIR_SLOTS 到 PAGE_LAST_INSERT 以及 PAGE_N_RECS 的意思大家一定是清楚的,不清楚翻看一下上文就能知道了)
- PAGE_DIRECTION
假如新插入的一条记录的主键值比上一条记录的主键值大,我们说这条记录的插入方向是右边,反之则是左 边。用来表示最后一条记录插入方向的状态就是 PAGE_DIRECTION
- PAGE_N_DIRECTION
假设连续几次插入新记录的方向都是一致的, InnoDB 会把沿着同一个方向插入记录的条数记下来,这个条 数就用 PAGE_N_DIRECTION 这个状态表示。当然,如果最后一条记录的插入方向改变了的话,这个状态的值会被清零重新统计
至于其他属性这篇文章暂时不会说,后面会慢慢详细讲解,因为涉及到内容在后面的文章里面
6 File Header(文件头部)
上边唠叨的 Page Header 是专门针对 数据页 记录的各种状态信息,比方说页里头有多少个记录了呀,有多少个槽了呀。我们现在描述的 File Header 针对各种类型的页都通用,也就是说不同类型的页都会以 File Header 作 为第一个组成部分,它描述了一些针对各种页都通用的一些信息,比方说这个页的编号是多少,它的上一个页、 下一个页是谁啦吧啦吧啦~ 这个部分占用固定的 38 个字节,是由下边这些内容组成的:
对照着这个表格,我们看几个目前比较重要的部分:
- FIL_PAGE_SPACE_OR_CHKSUM
这个代表当前页面的校验和(checksum)。啥是个校验和?就是对于一个很长很长的字节串来说,我们会 通过某种算法来计算一个比较短的值来代表这个很长的字节串,这个比较短的值就称为 校验和 。这样在比 较两个很长的字节串之前先比较这两个长字节串的校验和,如果校验和都不一样两个长字节串肯定是不同的,所以省去了直接比较两个比较长的字节串的时间损耗。
- FIL_PAGE_OFFSET
每一个页都有一个单独的页号,就跟你的身份证号码一样, InnoDB 通过页号来可以唯一定位一个 页
- FIL_PAGE_TYPE
这个代表当前 页 的类型,我们前边说过, InnoDB 为了不同的目的而把页分为不同的类型,我们上边介绍的 其实都是存储记录的 数据页 ,其实还有很多别的类型的页:
|类型名称|十六进制|描述| |:--:|:- -:|:--:| | FIL_PAGE_TYPE_ALLOCATED |0x0000|最新分配,还没使用| | FIL_PAGE_UNDO_LOG |0x0002|Undo日志页| | FIL_PAGE_INODE |0x0003|段信息节点| | FIL_PAGE_IBUF_FREE_LIST |0x0004|Insert Buffer空闲列表| | FIL_PAGE_IBUF_BITMAP |0x0005|Insert Buffer位图| | FIL_PAGE_TYPE_SYS |0x0006|系统页| | FIL_PAGE_TYPE_TRX_SYS |0x0007|事务系统数据| | FIL_PAGE_TYPE_FSP_HDR |0x0008|表空间头部信息| | FIL_PAGE_TYPE_XDES |0x0009|扩展描述页| | FIL_PAGE_TYPE_BLOB |0x000A|BLOB页| | FIL_PAGE_INDEX |0x45BF|索引页,也就是我们所说的 数据页 |
- FIL_PAGE_PREV 和 FIL_PAGE_NEXT
我们前边强调过, InnoDB 都是以页为单位存放数据的,有时候我们存放某种类型的数据占用的空间非常大 (比方说一张表中可以有成千上万条记录), InnoDB 可能不可以一次性为这么多数据分配一个非常大的存 储空间,如果分散到多个不连续的页中存储的话需要把这些页关联起来, FIL_PAGE_PREV 和 FIL_PAGE_NEXT 就分别代表本页的上一个和下一个页的页号。这样通过建立一个双向链表把许许多多的页就都串联起来了
而无需这些页在物理上真正连着。需要注意的是,并不是所有类型的页都有上一个和下一个页的属性,不过 我们本集中唠叨的数据页 (也就是类型为 FIL_PAGE_INDEX 的页)是有这两个属性的,所以所有的数据页其 实是一个双链表,就像这样:
7 File Trailer
我们知道 InnoDB 存储引擎会把数据存储到磁盘上,但是磁盘速度太慢,需要以 页 为单位把数据加载到内存中处 理,如果该页中的数据在内存中被修改了,那么在修改后的某个时间需要把数据同步到磁盘中。但是在同步了一 半的时候中断电了咋办,这不是莫名尴尬么?为了检测一个页是否完整(也就是在同步的时候有没有发生只同步 一半的尴尬情况),设计 InnoDB 的大叔们在每个页的尾部都加了一个 File Trailer 部分,这个部分由 8 个字节组成,可以分成2个小部分:
- 前4个字节代表页的校验和
这个部分是和 File Header 中的校验和相对应的。每当一个页面在内存中修改了,在同步之前就要把它的校 验和算出来,因为 File Header 在页面的前边,所以校验和会被首先同步到磁盘,当完全写完时,校验和也 会被写到页的尾部,如果完全同步成功,则页的首部和尾部的校验和应该是一致的。如果写了一半儿断电 了,那么在 File Header 中的校验和就代表着已经修改过的页,而在 File Trialer 中的校验和代表着原先 的页,二者不同则意味着同步中间出了错。
- 后4个字节代表页面被最后修改时对应的日志序列位置(LSN)
这个部分也是为了校验页的完整性的,只不过我们目前还没说 LSN 是个什么意思,所以大家可以先不用管这个属性。(这个LSN属性是要到很后面的章节才会讲解的,目前可以不用知道它是个什么)
这个 File Trailer 与 File Header 类似,都是所有类型的页通用的。
8 总结
1. InnoDB为了不同的目的而设计了不同类型的页,我们把用于存放记录的页叫做 数据页 。
2. 一个数据页可以被大致划分为7个部分,分别是
File Header ,表示页的一些通用信息,占固定的38字节。
Page Header ,表示数据页专有的一些信息,占固定的56个字节。
Infimum + Supremum ,两个虚拟的伪记录,分别表示页中的最小和最大记录,占固定的 26 个字节。
User Records :真实存储我们插入的记录的部分,大小不固定。
Free Space :页中尚未使用的部分,大小不确定。
Page Directory :页中的某些记录相对位置,也就是各个槽在页面中的地址偏移量,大小不固定,插 入的记录越多,这个部分占用的空间越多。
File Trailer :用于检验页是否完整的部分,占用固定的8个字节。
3. 每个记录的头信息中都有一个 next_record 属性,从而使页中的所有记录串联成一个 单链表 。 4. InnoDB 会为把页中的记录划分为若干个组,每个组的最后一个记录的地址偏移量作为一个 槽 ,存放在 Page Directory 中,所以在一个页中根据主键查找记录是非常快的,分为两步: 通过二分法确定该记录所在的槽。 通过记录的next_record属性遍历该槽所在的组中的各个记录。
5. 每个数据页的 File Header 部分都有上一个和下一个页的编号,所以所有的数据页会组成一个 双链表 。
6. 为保证从内存中同步到磁盘的页的完整性,在页的首部和尾部都会存储页中数据的校验和和页面最后修改时 对应的 LSN 值,如果首部和尾部的校验和和 LSN 值校验不成功的话,就说明同步过程出现了问题。
9 参考书籍
《MySQL是怎样运行的:从根儿上理解MySQL》小孩子4919 著
这本书写得非常好,推荐面试的小伙伴有时间可以去了解一下,对理解MySQL的帮助很大