MySQL-InnoDB-页结构

页结构

User Records、Free Space 部分说明

我们已经知道，记录在⻚中是按照主键值由小到大顺序串联成一个单链表放在 UserRecords 部分的。如果我们想根据主键值查找⻚中的某条记录该咋办?最笨的办法: 从 Infimum记录(最小记录)开始，沿着链表一直往后找，总有一天会找到(或者找不到)。在找的时候还能投机取巧，因为链表中各个记录的值是按照从小到大顺序排列的，所以当链表的某个节点代表的记录的主键值大于你想要查找的主键值时，你就可以停止查找了。这个方法在⻚中存储的记录数量比较少时也没啥问题，但如果一个⻚中存储了非常多的记录，遍历操作对性能来说还是有损耗的，所以说遍历查找这是一个笨办法。(时间复杂度很显然是 `O(n)`)

页内检索：单链表 的低效问题 

设计InnoDB的大叔们自然不会用上面那种笨办法，他们从现实中的书籍目录中找到了灵感。他们为页中的记录也制作了一个类似的目录。制作过程如下：将所有正常的记录(包括页内的最大和最小记录，不包括标记为已删除的记录) 划分为几个组 ；每个组的最后一条记录(也就是组内最大的那条记录)相当于“带头大哥”，组内其余的记录相当于“小弟”。“带头大哥”的记录头信息中的 n_owned 属性表示该组内共有几条记录；将每个组内最后一条记录(也就是 “带头大哥”)在页面中的地址偏移量(就是该条记录与页面中第0个字节之间的距离)单独提取出来并且还按主键顺序存储到靠近⻚尾的地方，这个地方就是所谓的 Page Directory，也就是`⻚目录`。⻚目录中的这些地址偏移量被称为 槽span style=\

书籍目录的灵感引出Page Directory

比方说现在的demo表中正常的记录共有6条，InnoDB会把它们分成两组，第一组中只有一个最小记录，第二组中是剩余的5条记录，2个组就对应着两个槽，每个槽中存放着每个组中最大的那条记录在页面中的地址偏移量:

接着，我们一口气又往表中添加了12条记录，现在⻚里边就一共有18条记录了(包括最小和最大记录)，这些记录被分成了5个组: (图中只保留了用户记录头信息中的n_owned和next_record属性，也省略了各个记录之间的箭头!)

Page Directory 图例演示

Page Directory 的使用

Page Directory (⻚目录) 部分说明

PAGE_N_DIR_SLOTS

PAGE_HEAP_TOP

PAGE_N_HEAP

PAGE_FREE

PAGE_GARBAGE

PAGE_LAST_INSERT

PAGE_DIRECTION

PAGE_N_DIRECTION

PAGE_N_RECS

PAGE_MAX_TRX_ID

PAGE_LEVEL

PAGE_INDEX_ID

PAGE_BTR_SEG_LEAF

PAGE_BTR_SEG_TOP

Page Header(⻚面头部) 部分各属性说明

3. 数据(索引)页 结构

FIL_PAGE_SPACE_OR_CHKSUM

FIL_PAGE_OFFSET

FIL_PAGE_TYPE

FIL_PAGE_PREV、FIL_PAGE_NEXT

FIL_PAGE_LSN 

FIL_PAGE_FILE_FLUSH_LSN

FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID

其他属性暂时用不到，等用到时再提~

File Header(文件头部) 部分各属性说明

File Trailer(文件尾部) 部分

4. 通用页 结构

首先你要明白的是： InnoDB存储引擎最基础且主要的一个特点是 “表中的数据是存储到磁盘上的”。(即便服务宕机重启后，数据也还是存在的，这点不像一些内存型数据库)尽管数据是存储到磁盘上的，但数据的处理肯定是发生在内存中的。数据的读写操作，自然也就涉及到 将磁盘中的数据加载到内存中 和 把内存中的内容刷新到磁盘上 的这两类操作。

当我们从表中获取记录时，InnoDB存储引擎是一条一条的把记录从磁盘上读出来么?   要知道 读写磁盘 和 内存读写 的速度相比，那可差了几个数量级嘞！ 一次磁盘IO那么慢，你一次却只取一条数据......，那不慢死了。

1. 为什么设计者要搞出个页的概念？

2. InnoDB 多种不同的页类型

外框

所以 InnoDB 提出了一个叫做⻚的概念，b style=\