页是InnoDB存储引擎管理存储空间的基本单位,一个页的大小默认是16KB 。InnoDB 为了不同的目的而设计了许多种不同类型的页 ,比如存放记录的索引页,存放表空间头部信息的页,存放 Insert Buffer信息的页,存放 INODE 信息的页,存放 undo 日志信息的页等等。在这我们主要关注的是存放我们表中记录的那种类型的页,官方称这种存放记录的页为索引( INDEX )页,其实这些页中的记录就是我们存储的数据记录 ,所以这种存放记录的页也可以称为数据页。
数据页代表的这块默认的16KB大小的存储空间可以被划分为多个部分,不同部分有不同的功能,各个部分如图所示:
从上图可以看出,一个 InnoDB 数据页的存储空间大致被划分成了 7 个部分,有的部分占用的字节数是确定的,有的部分占用的字节数是不确定的。各部分的介绍如下表:
名称 | 中文名 | 占用空间大小 | 简单描述 |
---|---|---|---|
File Header | 文件头部 | 38 字节 | 页的一些通用信息 |
Page Header | 页面头部 | 56 字节 | 数据页专有的一些信息 |
Infimum + Supremum | 最小记录和最大记录 | 26 字节 | 两个虚拟的行记录 |
User Records | 用户记录 | 不确定 | 实际存储的行记录内容 |
Free Space | 空闲空间 | 不确定 | 页中尚未使用的空间 |
Page Directory | 页面目录 | 不确定 | 页中的某些记录的相对位置 |
File Trailer | 文件尾部 | 8 字节 | 校验页是否完整 |
在页的7个组成部分中,用户数据会按照我们指定的行格式存储到 User Records 部分。但是在一开始生成页的时候,其实并没有 User Records 这个部分,每当我们插入一条记录,都会从 Free Space 部分,也就是尚未使用的存储空间中申请一个记录大小的空间划分到 User Records 部分,当 Free Space 部分的空间全部被User Records 部分替代掉之后,也就意味着这个页使用完了,如果还有新的记录插入的话,就需要去申请新的页了,这个过程的图示如下:
InnoDB如何存放一条一条的记录信息,并能准群的找到它的上一页下一页的位置,这些都是通过记录头信息实现的。
为方便测试说明,先创建一个测试表:
mysql> create table page_demo(c1 int,c2 int ,c3 varchar(1000),primary key(c1)) charset=ascii row_format=compact;
Query OK, 0 rows affected (0.09 sec)
这个新创建的表有3个列,其中c1和c2列用来存储整数,c3列用来存储字符串。注意,上面已经把c1列指定为主键,所以在具体的行格式中InnoDB就没必要为再去创建 row_id 这个隐藏列。此外为这个表指定了ascii字符集以及Compact 的行格式。所以这个表中记录的行格式示意图大致如下:
从图中可以看到记录额外信息中记录头信息是5个字节共包括8个属性(以compact 行格式为例),包括的属性大致说明如下:
名称 | 大小 | (单位:bit)描述 |
---|---|---|
预留位1 | 1 | 没有使用 |
预留位2 | 1 | 没有使用 |
delete_mask | 1 | 标记该记录是否被删除 |
min_rec_mask | 1 | B+树的每层非叶子节点中的最小记录都会添加该标记 |
n_owned | 4 | 表示当前记录拥有的记录数(以组统计最后一行表示) |
heap_no | 13 | 表示当前记录在记录堆的位置信息 |
record_type | 3 | 表示当前记录的类型, 0 表示普通记录, 1 表示B+树非叶节点记录, 2 表示最小记录, 3表示最大记录 |
next_record | 16 | 表示下一条记录的相对位置 |
我们往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.07 sec)
Records: 4 Duplicates: 0 Warnings: 0
为了方便分析这些记录在页的User Records 部分中是怎么表示的,此处把记录中头信息和实际的列数据都用十进制表示出来了(其实真实是一堆二进制),然后这些记录的示意图如下:
注意,各条记录在 User Records 中存储的时候并没有空隙,这里只是为了观看方便才把每条记录单独画在一行。我们对照着这个图来看看记录头信息中的各个属性的用途:
一条完整的记录
来说,比较记录的大小就相当于比的是主键的大小。后边我们还会遇到只存储一条记录的部分列的情况,后续再做分享。但是不管我们向页中插入了多少自己的记录,InnoDB规定他们都会在页中插入两条伪记录分别为最
小记录与最大记录。这两条记录的构造十分简单,都是由5字节大小的记录头信息和8字节大小的一个固定的部分组成的,如下图所示:
由于这两条记录不是我们自己的数据记录,所以它们并不存放在页的 User Records 部分,他们被单独放在一个称为 Infimum + Supremum 的部分,如图所示:
从上图我们可以看到,最小记录和最大记录的 heap_no 值分别是 0 和 1 ,也就是说它们的位置最靠前。
mysql> delete from page_demo where c1 = 2;
Query OK, 1 row affected (0.04 sec)
删掉第2条记录后的示意图会变成如下:
从图中可以看出来,删除第2条记录前后主要发生了这些变化:
上面,因为主键值为 2 的记录被我们删掉了,但是存储空间却没有回收,如果我们很快再次把这条记录又插入到表中,会发生什么事呢?
mysql> insert into page_demo values(2, 200, 'bbbb');
Query OK, 1 row affected (0.03 sec)
记录的存储情况会变成如下所示:
从上图可以看到,InnoDB 并没有因为新记录的插入而为它申请新的存储空间,而是直接复用了原来被删除记录的存储空间。
注意:当数据页中存在多条被删除掉的记录时,这些记录的next_record属性将会把这些被删除掉的记录组成一个垃圾链表,以备之后重用这部分存储空间。
现在我们了解了记录在页中按照主键值由小到大顺序串联成一个单链表,那如果我们想根据主键值查找页中的某条记录该咋办呢?比如说这样的查询语句:
select * from page_demo WHERE c1 = 2;
最笨的办法:从 Infimum 记录(最小记录)开始,沿着链表一直往后找,总会找到(或者找不到,本来就没有),在找的时候还能投机取巧,因为链表中各个记录的值是按照从小到大顺序排列的,所以当链表的某个节点代表的记录的主键值大于你想要查找的主键值时,你就可以停止查找了,因为该节点后边的节点的主键值依次递增。
这个方法在页中存储的记录数量比较少的情况影响不大,比方现在我们的表里只有 4 条自己插入的记录,所以最多找4次就可以把所有记录都遍历一遍,但是如果一个页中存储了非常多的记录,这么查找对性能来说还是有损耗的,所以我们说这种遍历查找这是一个笨办法。当然InnoDB是不会这样去查找的。
我们平常想从一本书中查找某个内容的时候,一般会先看目录,找到需要查找的内容对应的书的页码,然后到对应的页码查看内容。InnoDB 其实也有一个类似的目录,它的制作过程如下:
1 .将所有正常的记录(包括最大和最小记录,不包括标记为已删除的记录)划分为几个组(同一页中的)。
2 .每个组的最后一条记录(也就是组内最大的那条记录)的头信息中的 n_owned属性表示该记录拥有多少条记录,也就是该组内共有几条记录。
3 .将每个组的最后一条记录的地址偏移量单独提取出来按顺序存储到靠近页的尾部的地方,这个地方就是所谓的 Page Directory (大小不确定),也就是页目录 。页面目录中的这些地址偏移量被称为槽 (英文名: Slot ),所以这个页面目录就是由槽组成的。
比方说现在的 page_demo 表中正常的记录共有6条, InnoDB 会把它们分成两组,第一组中只有一个最小记录,第二组中是剩余的5条记录,看下边的示意图:
从这个图中我们需要注意这么几点:
现在页目录部分中有两个槽,也就意味着我们的记录被分成了两个组,槽0中的值是 99 ,代表最小记录的地址偏移量(就是从页面的0字节开始数,数99个字节);槽1中的值是112 ,代表最大记录的地址偏移量。
最小和最大记录的头信息中的 n_owned 属性,也就是各分组中的记录数。
但为什么最小记录的 n_owned 值为1,而最大记录的 n_owned 值为 5 呢,这是怎么得出来的呢?
是由于InnoDB 对每个分组中的记录条数是有规定的:对于最小记录所在的分组只能有 1 条记录,
最大记录所在的分组拥有的记录条数只能在 1-8条之间,剩下的分组中记录的条数范围只能在是 4~8 条之间。
所以分组是按照下边的步骤进行的:
初始情况下一个数据页里只有最小记录和最大记录两条记录,它们分属于两个分组。
之后每插入一条记录,都会从页目录中找到主键值比本记录的主键值大并且差值最小的槽,然后把该槽对应的记录的 n_owned 值加1,表示本组内又添加了一条记录,直到该组中的记录数等于8个。
在一个组中的记录数等于8个后再插入一条记录时,会将组中的记录拆分成两个组,一个组中4条记录,另一个5条记录。这个过程会在页目录中新增一个槽来记录这个新增分组中最大的那条记录的偏移量。由于现在 page_demo 表中的记录太少,无法演示添加了页目录之后加快查找速度的过程,所以再往 page_demo
表中添加一些记录:
mysql> insert into page_demo values(5, 500, 'eeee'), (6, 600, 'ffff'), (7, 700, 'gggg'),
-> (8, 800, 'hhhh'), (9, 900, 'iiii'), (10, 1000, 'jjjj'), (11, 1100, 'kkkk'), (12, 1200, 'l
'> lll'), (13, 1300, 'mmmm'), (14, 1400, 'nnnn'), (15, 1500, 'oooo'), (16, 1600, 'pppp');
Query OK, 12 rows affected (0.02 sec)
Records: 12 Duplicates: 0 Warnings: 0
插入后现在页里边就一共有18条记录了(包括最小和最大记录),这些记录被分成了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条,所以遍历一个组中的记录的代价是很小的。
所以在一个数据页中查找指定主键值的记录的过程分为两步:
InnoDB 为了能得到一个数据页中存储的记录的状态信息,如本页中已经存储了多少条记录,第一条记录的地址是什么,页目录中存储了多少个槽(也就是分了多少个组)等等,特意在页中定义了一个叫 Page Header 的部分,它是页结构的第二部分,这个部分占用固定的 56 个字节,专门存储各种状态信息,具体各个字节作用如下表:
名称 | 占用空间大小 | 描述 |
---|---|---|
PAGE_N_DIR_SLOTS | 2 字节 | 在页目录中的槽数量 |
PAGE_HEAP_TOP | 2 字节 | 还未使用的空间最小地址,也就是说从该地址之后就是 Free Space |
PAGE_N_HEAP 2 | 字节 | 本页中的记录的数量(包括最小和最大记录以及标记为删除的记录) |
PAGE_FREE 2 | 字节 | 第一个已经标记为删除的记录地址(各个已删除的记录通过 next_record 也会组成一个单链表,这个单链表中的记录可以被重新利用) |
PAGE_GARBAGE | 2 字节 | 已删除记录占用的字节数 |
PAGE_LAST_INSERT | 2 字节 | 最后插入记录的位置 |
PAGE_DIRECTION | 2 字节 | 记录插入的方向 |
PAGE_N_DIRECTION | 2 字节 | 一个方向连续插入的记录数量 |
PAGE_N_RECS | 2 字节 | 该页中记录的数量(不包括最小和最大记录以及被标记为删除的记录) |
PAGE_MAX_TRX_ID | 8 字节 | 修改当前页的最大事务ID,该值仅在二级索引中定义 |
PAGE_LEVEL | 2 字节 | 当前页在B+树中所处的层级 |
PAGE_INDEX_ID | 8 字节 | 索引ID,表示当前页属于哪个索引 |
PAGE_BTR_SEG_LEAF | 10 字节 | B+树叶子段的头部信息,仅在B+树的Root页定义 |
PAGE_BTR_SEG_TOP | 10 字节 | B+树非叶子段的头部信息,仅在B+树的Root页定义 |
其中PAGE_DIRECTION 和 PAGE_N_DIRECTION 的意思如下:
Page Header 是专门针对数据页记录的各种状态信息,比方说页里头有多少个记录,有多少个
槽等。我们现在描述的 File Header 针对各种类型的页都通用,也就是说不同类型的页都会以 File Header 作为第一个组成部分,它描述了一些针对各种页都通用的一些信息,比方说这个页的编号是多少,它的上一个页、下一个页是等, 这个部分占用固定的 38 个字节,具体各字节作用如下表:
名称 | 占用空间大小 | 描述 |
---|---|---|
FIL_PAGE_SPACE_OR_CHKSUM | 4 字节 | 页的校验和(checksum值) |
FIL_PAGE_OFFSET | 4 字节 | 页号 |
FIL_PAGE_PREV | 4 字节 | 上一个页的页号 |
FIL_PAGE_NEXT | 4 字节 | 下一个页的页号 |
FIL_PAGE_LSN | 8 字节 | 页面被最后修改时对应的日志序列位置(英文名是:Log Sequence Number)FIL_PAGE_TYPE |
FIL_PAGE_FILE_FLUSH_LSN | 8 字节 | 仅在系统表空间的一个页中定义,代表文件至少被刷新到了对应的LSN值 |
FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID | 4 字节 | 页属于哪个表空间 |
对照着上面表格,我们看几个目前比较重要的参数:
类型名称 | 十六进制 | 描述 |
---|---|---|
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_INDEX ,也就是所谓的索引页 。
我们知道 InnoDB 存储引擎会把数据存储到磁盘上,但是磁盘速度太慢,需要以页为单位把数据加载到内存中处理,如果该页中的数据在内存中被修改了,那么在修改后的某个时间需要把数据同步到磁盘中。但是在同步了一半的时候中断电了咋办,这不是莫名尴尬么?为了检测一个页是否完整(也就是在同步的时候有没有发生只同步一半的尴尬情况),设计 InnoDB 的大叔们在每个页的尾部都加了一个 File Trailer 部分,这个部分由 8 个字节组成,可以分成2个小部分:
这个 File Trailer 与 File Header 类似,都是所有类型的页通用的。
更多关于mysql的知识分享,请前往博客主页。编写过程中,难免出现差错,敬请指出