做彩网站有哪些,php网站开发技术训练心得,音乐网站页面设计,网站更换服务器 备案概述
表空间是一个在 InnoDB 中比较抽象的概念#xff0c;对于系统表空间来说#xff0c;对应着文件系统中一个或多个实际文件#xff1b;而对于每个独立表空间来说#xff0c;对应着文件系统中一个名为表名.ibd 的实际文件。可以把表空间想象成由很多个页组成的池子…概述
表空间是一个在 InnoDB 中比较抽象的概念对于系统表空间来说对应着文件系统中一个或多个实际文件而对于每个独立表空间来说对应着文件系统中一个名为表名.ibd 的实际文件。可以把表空间想象成由很多个页组成的池子pool当我们想为某个表插入一条记录的时候就会从对应的池子中选一个合适的页将数据写进去。
Innodb中的页
页面类型
InnoDB是以页为单位管理存储空间的我们的聚簇索引也就是完整的表数据和其他的二级索引都是以 B 树的形式保存到表空间的而 B 树的节点就是数据页。数据页的类型名使用字段FIL_PAGE_INDEX简写为INDEX表示 除了这种存放索引数据的页面类型之外InnoDB也为了不同的用途设计了很多其他类型的页面。如allocation未分配页、undo_logundo日志页、redo_log 等。
页面通用部分
前边说过数据页也就是 INDEX 类型的页由7个部分组成其中的两个部分File Header 和 File Trailer是所有类型页面都通用的。如下任何类型的页面都有下边这种通用的结构 从上图中可以看出任何类型的页都会包含这两个部分
File Header 记录页面的一些通用信息File Trailer 校验页是否完整保证从内存到磁盘刷新时内容的一致性。
File Header 的各个组成部分如下
名称占用空间大学说明FIL_PAGE_SPACE_OR_CHKSUM4 字节页的校验和checksum值FIL_PAGE_OFFSET4 字节页号FIL_PAGE_PREV4 字节上一个页的页号FIL_PAGE_NEXT4 字节下一个页的页号FIL_PAGE_LSN8 字节页面被最后修改时对应的日志序列位置英文名是Log Sequence NumberFIL_PAGE_TYPE2 字节该页的类型FIL_PAGE_FILE_FLUSH_LSN8 字节仅在系统表空间的一个页中定义代表文件至少被刷新到了对应的LSN值FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID4 字节页属于哪个表空间
说明几点
表空间中的每一个页都有一个页号也就是 FIL_PAGE_OFFSET 这个页号由4个字节组成共32个比特位所以一个表空间理论上最多可以拥有2³²个页如果按照页的默认大小16KB计算一个表空间最多可以存储64TB的数据。表空间的第一个页的页号为0之后的页号分别是123…依此类推。某些类型的页可以组成链表链表中的页可以不按照物理顺序存储而是根据 FIL_PAGE_PREV 和 FIL_PAGE_NEXT 来存储上一个页和下一个页的页号。需要注意的是这两个字段主要是为了INDEX类型数据页的页建立 B 树后为每层节点建立双向链表用的一般类型的页是不使用这两个字段的。每个页的类型由 FIL_PAGE_TYPE 表示如数据页的该字段的值就是 0x45BF 其他不同类型的页后续介绍。
独立表空间结构
InnoDB 支持许多种类型的表空间作为用户我们的数据一般都是以独立表空间结构类型来存储的。系统表空间和独立表空间的结构比较相似只是系统表空间中额外包含了一些关于整个系统的信息。本章节我们先看一看独立表空间结构类型。
区extent的概念
表空间中的页可以有很多为了更好的管理这些页面InnoDB 中提出了区 extent 的概念。对于16KB的页来说连续的64个页就是一个区 也就是说一个区默认占用1MB空间大小。不论是系统表空间还是独立表空间都可以看成是由若干个区组成的每256个区被划分成一组。示意图如下 其中 extent 0 ~extent 255 这256个区算是第一个组 extent 256 ~ extent 511 这256个区算是第二个组 extent 512 ~ extent 767 这256个区算是第三个组依此类推。这些组的头几个页面结构如下 从上图中我们能得到如下信息 第一个组最开始的3个页面的类型是固定的 也就是说 extent 0 这个区最开始的3个页面的类型是固定的分别是
FSP_HDR 类型这个类型的页面是用来登记整个表空间的一些整体属性以及本组所有的区 也就是extent 0 ~ extent 255 这256个区的属性。需要注意的一点是整个表空间只有一个 FSP_HDR 类型的页面。IBUF_BITMAP 类型这个类型的页面是存储本组所有的区的所有页面关于 INSERT BUFFER 的信息 后边会详细说这个类型。INODE 类型这个类型的页面存储了许多称为 INODE 的数据结构。
其余各组最开始的2个页面的类型是固定的也就是说 extent 256 、extent 512 这些区最开始的2个页面的类型是固定的分别是
XDES 类型全称是 extent descriptor区描述符 用来登记本组256个区的属性也就是说对于在 extent 256区中的该类型页面存储的就是 extent 256 ~ extent 511 这些区的属性对于在 extent 512 区中的该类型页面存储的就是 extent 512 ~ extent 767 这些区的属性**。这与上边介绍的 FSP_HDR 类型作用类似只不过 FSP_HDR 类型的页面还会额外存储一些表空间的属性。**IBUF_BITMAP 类型如上。 总结表空间被划分为许多连续的区 每个区默认由64个页组成每256个区划分为一组每个组的最开始的几个页面类型是固定的。
段segment的概念
如果我们表中数据量很少的话用一页或者几页可能就可以将数据全部存储完全用不到区的概念但如果表里的记录越来越多呢B 树的每一层中的页都会形成一个双向链表 File Header 中的FIL_PAGE_PREV 和 FIL_PAGE_NEXT 字段就是为了形成双向链表设置的。从理论上说不要区这个概念只使用页的概念对存储引擎的运行并没什么影响但是我们来看看下边这个场景
我们每向表中插入一条记录本质上就是向该表的聚簇索引以及所有二级索引代表的 B 树的节点中插入数据。而 B 树的每一层中的页都会形成一个双向链表如果是以页为单位来分配存储空间的话双向链表相邻的两个页之间的物理位置可能离得非常远。我们介绍 B 树索引的适用场景的时候特别提到范围查询只需要定位到最左边的记录和最右边的记录然后沿着双向链表一直扫描就可以了而如果链表中相邻的两个页物理位置离得非常远就是所谓的随机I/O 。而随机I/O 是非常慢的所以我们应该尽量让链表中相邻的页的物理位置也相邻这样进行范围查询的时候才可以使用所谓的顺序I/O 。
所以才引入了 区 extent 的概念一个区就是在物理位置上连续的64个页。在表中数据量大的时候为某个索引分配空间的时候就不再按照页为单位分配了而是按照区为单位分配甚至在表中的数据非常多的时候可以一次性分配多个连续的区。 虽然可能造成部分空间的浪费数据不足填充满整个区但是从性能角度看可以消除很多的随机 I/O 。
我们提到的范围查询其实是对 B 树叶子节点中的记录进行顺序扫描但如果不区分叶子节点和非叶子节点全部把节点代表的页面放到申请到的区中的话进行范围扫描的效果就会降低。所以InnoDB 对 B 树的叶子节点和非叶子节点进行了区别对待也就是说叶子节点有自己独有的区 非叶子节点也有自己独有的区 。存放叶子节点的区的集合就算是一个段 segment 存放非叶子节点的区的集合也算是一个段 。也就是说一个索引会生成2个段一个叶子节点段一个非叶子节点段。
默认情况下一个使用 InnoDB 存储引擎的表只有一个聚簇索引一个索引会生成2个段可以理解为数据段目录段而段是以区为单位申请存储空间的一个区默认占用1M存储空间所以默认情况下一个只存了几条记录的表也需要2M的存储空间么以后每次添加一个索引都要多申请2M的存储空间么这对于存储记录比较少的表肯定是浪费。然而在InnoDB中也考虑到了这种情况。这个问题的原因在于到现在为止我们介绍的区都是非常单一的也就是一个区被整个分配给某一个段或者说区中的所有页面都是为了存储同一个段的数据而存在的即使段的数据填不满区中所有的页面那剩下的页面也会闲置。现在需要考虑以完整的区为单位分配给某个段对于数据量较小的表太浪费存储空间的这种情况于是在InnoDB 中提出了碎片fragment区的概念也就是在一个碎片区中并不是所有的页都是为了存储同一个段的数据而存在的而是碎片区中的页可以用于不同的目的比如有些页用于段A有些页用于段B有些页甚至哪个段都不属于还未使用。碎片区直属于表空间并不属于任何一个段。所以此后为某个段分配存储空间的策略是这样的
在刚开始向表中插入数据的时候段是从某个碎片区以单个页面为单位来分配存储空间的。当某个段已经占用了32个碎片区页面之后就会以完整的区为单位来分配存储空间。
所以现在段不能仅定义为是某些区的集合更精确的应该是某些零散的页面以及一些完整的区的集合。除了索引的叶子节点段和非叶子节点段之外 InnoDB 中还有为存储一些特殊的数据而定义的段比如回滚段等等。
区的分类
从上面我们知道表空间的是由若干个区组成的这些区大体上可以分为4种类型:
空闲的区:现在还没有用到这个区中的任何页面。有剩余空间的碎片区:表示碎片区中还有可用的页面。没有剩余空间的碎片区:表示碎片区中的所有页面都被使用没有空闲页面。附属于某个段的区。每一个索引都可以分为叶子节点段和非叶子节点段除此之外InnoDB还会另外定义一些 特殊作用的段在这些段中的数据量很大时将使用区来作为基本的分配单位。可以理解为该区全部储存的某个段的数据
这4种类型的区也可以被称为区的4种状态( State )如下
状态名含义FREE空闲的区FREE_FRAG有剩余空间的碎片区FULL_FRAG没有剩余空间的碎片区FSEG附属于某个段的区
说明处于 FREE 、 FREE_FRAG 以及 FULL_FRAG 这三种状态的区都是独立的算是直属于表空间而处于 FSEG状态的区是附属于某个段的。如果把表空间比作是一个集团军段就相当于师区就相当于团。一般的团都是隶属于某个师的就像处于FSEG的区团全都隶属于某个段师而处于FREE、FREE_FRAG以及FULL_FRAG这三种状态的区却直接隶属于表空间就像独立团直接听命于军部一样。 为了方便管理这些区设计 InnoDB 的人设计了一个称为 XDES Entry 的结构 (全称就是Extent Descriptor Entry翻译为区段描述符条目) 每一个区都对应着一个 XDES Entry 结构这个结构记录了对应的区的一些属性。我们先看图来对这个 结构有个大致的了解 从图中我们可以看出 XDES Entry 是一个40个字节的结构大致分为4个部分各个部分的释义如下
Segment ID 8字节 每一个段都有一个唯一的编号用ID表示此处的 Segment ID 字段表示就是该区所在的段。当然前提是该区已经附属于某个段不然的话该字段的值没有意义。List Node 12字节 这个部分可以将多个 XDES Entry 区结构串联成一个区链表下面看一下这个 List Node 的结构 如果我们想定位表空间内的某一个位置的话只需指定页号以及该位置在指定页号中的页内偏移量即可。所以 Pre Node Page Number 和 Pre Node Offset 的组合就是指向前一个 XDES Entry 的指针。Next Node Page Number 和 Next Node Offset 的组合就是指向后一个 XDES Entry 的指针。
这些 XDES Entry 结构管理区的连成一个链表而每个链表对应的 List Base Node 结构放置在表空间中的固定位置这样就可以很容易地定位某个链表了。
State 4字节 这个字段表代表区的状态。可选的值有4个分别是FREE 、FREE_FRAG 、FULL_FRAG和 FSEG 代表的意思见上面的介绍。Page State Bitmap 16字节 这个部分共占用16个字节也就是128个比特位。我们知道一个区默认有64个页这128个比特位被划分为64个部分每个部分2个比特位对应区中的一个页。比如 Page State Bitmap 部分的第1和第2个比特位对应着区中的第1个页面第3和第4个比特位对应着区中的第2个页面依此类推 Page State Bitmap 部分的第127和128个比特位对应着区中的第64个页面。这两个比特位的第一个位表示对应的页是否是空闲的第二个比特位还没有用。
XDES Entry链表
上面我们已经了解了很多新的概念包括区、段、碎片区、附属于段的区、 XDES Entry 结构等等提出这些概念的目的一方面是想提高向表插入数据的效率同时在数据量少的时候减少表空间的浪费。现在我们知道向表中插入数据本质上就是向表中各个索引的叶子节点段、非叶子节点段插入数据也知道区有不同的状态。下面我们想一想向某个段中插入数据的过程
当段中数据较少的时候首先会查看表空间中是否有状态为 FREE_FRAG 的区也就是找还有空闲空间的碎片区如果找到了那么从该区中取一些零碎的页把数据插进去否则到表空间下申请一个状态为 FREE 的区也就是空闲的区把该区的状态变为 FREE_FRAG 然后从该新申请的区中取一些零碎的页把数据插进去。之后不同的段使用零碎页的时候都会从该区中取直到该区中没有空闲空间然后该区的状态就变成了FULL_FRAG 。 现在的问题是如何区分表空间中的哪些区是 FREE 的哪些区的状态是 FREE_FRAG 的哪些区是FULL_FRAG 的要知道当记录数很多时区的数量也就很多每次都要遍历这些区对应的 XDES Entry 结构是耗时耗性能的这时候就是 XDES Entry 中的 List Node 部分就可以用上了我们可以通过 List Node 中的指针做这么三件事 把状态为 FREE 的区对应的 XDES Entry 结构通过 List Node 来连接成一个链表这个链表我们就称之为 FREE 链表。把状态为 FREE_FRAG 的区对应的 XDES Entry 结构通过 List Node 来连接成一个链表这个链表我们就称之为 FREE_FRAG 链表。把状态为 FULL_FRAG 的区对应的 XDES Entry 结构通过 List Node 来连接成一个链表这个链表我们就称之为 FULL_FRAG 链表。
这样每当我们想找一个 FREE_FRAG 状态的区时就直接把 FREE_FRAG 链表的头节点拿出来从这个节点中取一些零碎的页来插入数据当这个节点对应的区用完时就修改一下这个节点的 State 字段的值然后从 FREE_FRAG 链表中移到 FULL_FRAG 链表中。同理如果 FREE_FRAG 链表中一个节点都没有那么就直接从 FREE 链表中取一个节点移动到 FREE_FRAG 链表的状态并修改该节点的 STATE 字段值为FREE_FRAG 然后从这个节点对应的区中获取零碎的页就可以使用了。
当段中数据已经占满了32个零散的页后就直接申请完整的区来插入数据了。 那么我们怎么知道哪些区属于哪个段的呢当然是使用链表。我们按段使用不同的链表有多少个段就建多少个链表并根据使用状态进行细分。InnoDB 中为每个段中的区对应的 XDES Entry 结构建立了三个链表FREE 链表同一个段中所有页面都是空闲的区对应的 XDES Entry 结构会被加入到这个链表。注意和直属于表空间的 FREE 链表区别开了此处的 FREE 链表是附属于某个段的。NOT_FULL 链表同一个段中仍有空闲空间的区对应的 XDES Entry 结构会被加入到这个链表。FULL 链表同一个段中已经没有空闲空间的区对应的 XDES Entry 结构会被加入到这个链表。 按上面所说每一个索引都对应两个段每个段都会维护上述的3个链表比如下边这个表 CREATE TABLE t ( c1 INT NOT NULL AUTO_INCREMENT, c2 VARCHAR(100), c3 VARCHAR(100), PRIMARY KEY (c1), KEY idx_c2 (c2) )ENGINEInnoDB; 这个表 t 共有两个索引一个聚簇索引一个二级索引 idx_c2 所以这个表共有4个段每个段都会维护上述3个链表总共是12个链表36n个链表 其中n为索引数量加上我们上边说过的直属于表空间的3个链表整个独立表空间共需要维护15个链表。所以段在数据量比较大时插入数据的话会先获取 NOT_FULL 链表的头节点直接把数据插入这个头节点对应的区中即可如果该区的空间已经被用完就把该节点移到 FULL 链表中。
链表基节点
实际使用中我们怎么找到某个链表的头节点或者尾节点在表空间中的位置呢 InnoDB 中设计了一个叫 List Base Node 的结构大意就是链表的基节点。这个结构中包含了链表的头节点和尾节点的指针以及这个链表中包含了多少节点的信息我们画图看一下这个结构的示意图 我们上边介绍的每个链表都对应这么一个 List Base Node 结构其中
List Length 表明该链表一共有多少节点First Node Page Number 和 First Node Offset 表明该链表的头节点在表空间中的位置。 Last Node Page Number 和 Last Node Offset 表明该链表的尾节点在表空间中的位置。
一般我们把某个链表对应的 List Base Node 结构放置在表空间中固定的位置这样想找定位某个链表就很简单了。
链表小结
综上所述表空间我们一般都为每个表分配了一个独立的表空间是由若干个区组成的每个区都对应一个 XDES Entry 的结构直属于表空间的区对应的 XDESEntry 结构可以分成 FREE 、 FREE_FRAG 和 FULL_FRAG 这3个链表每个段可以附属若干个区每个段中的区对应的 XDES Entry 结构可以分成 FREE 、 NOT_FULL 和 FULL 这3个链表。每个链表都对应一个 List Base Node 的结构这个结构里记录了链表的头、尾节点的位置以及该链表中包含的节点数。通过这些链表的存在很容易地就可以管理这些区。
段的结构
段其实不对应表空间中某一个连续的物理区域而是一个逻辑上的概念由若干个零散的页面以及一些完整的区组成。像每个区都有对应的 XDES Entry 来记录这个区中的属性一样InnoDB 中为每个段都定义了一个 INODE Entry 结构来记录一下段中的属性。如下图所示 说明如下
Segment ID就是指这个 INODE Entry 结构对应的段的编号ID。 NOT_FULL_N_USED 这个字段指的是在 NOT_FULL 链表中已经使用了多少个页面。下次从 NOT_FULL 链表分配空闲页面时可以直接根据这个字段的值定位到。而不用从链表中的第一个页面开始遍历着寻找空闲页面。3个 List Base Node 分别为段的 FREE 链表、 NOT_FULL 链表、 FULL 链表定义了 List Base Node 这样我们想查找某个段的某个链表的头节点和尾节点的时候就可以直接到这个部分找到对应链表的 List Base Node 。Magic Number 这个值是用来标记这个 INODE Entry 是否已经被初始化了初始化的意思就是把各个字段的值都填进去了。如果这个数字是值的 97937874 表明该 INODE Entry 已经初始化否则没有被初始化。这个书数字就是规定的。Fragment Array Entry 我们知道段是一些零散页面和一些完整的区的集合每个 Fragment Array Entry 结构都对应着一个零散的页面这个结构一共4个字节表示一个零散页面的页号。
各类型页面详细情况
FSP_ HDR 类型
首先看第一个组的第一个页面当然也是表空间的第一个页面页号为 0 。这个页面的类型是 FSP_HDR 它存储了表空间的一些整体属性以及第一个组内256个区的对应的 XDES Entry 结构直接看这个类型的页面的示意图 从图中可以看出一个完整的 FSP_HDR 类型的页面大致由5个部分组成各个部分的解释如下
名称中文名占用空间大小简单描述File Header文件头部38 字节页的一些通用信息File Space Header表空间头部112 字节表空间的一些整体属性信息XDES Entry区描述信息10240 字节存储本组256个区对应的属性信息Empty Space尚未使用空间5986 字节用于页结构的填充没啥实际意义File Trailer文件尾部8 字节校验页是否完整
我们重点看看 File Space Header 和 XDES Entry 这两个部分。
File Space Header部分 从名字就可以看出来这个部分是用来存储表空间的一些整体属性的如下图
看看每个字段含义的简单描述
名称占用空间 大小描述Space ID4 字节表空间的IDNot Used4 字节这4个字节未被使用可以忽略Size4 字节当前表空间占有的页面数FREE Limit4 字节尚未被初始化的最小页号大于或等于这个页号的区对应的XDES Entry结构都没有被加入FREE链表Space Flags4 字节表空间的一些占用存储空间比较小的属性FRAG_N_USED4 字节FREE_FRAG链表中已使用的页面数量List Base Node for FREE List16 字节FREE链表的基节点List Base Node for FREE_FRAG List16 字节FREE_FREG链表的基节点List Base Node for FULL_FRAG List16 字节FULL_FREG链表的基节点Next Unused Segment ID8 字节当前表空间中下一个未使用的Segment IDList Base Node for SEG_INODES_FULL List16 字节SEG_INODES_FULL链表的基节点List Base Node for SEG_INODES_FREE List16 字节SEG_INODES_FREE链表的基节点
部分字段说明
List Base Node for FREE List 、 List Base Node for FREE_FRAG List 、 List Base Node for FULL_FRAG List 。 这三个分别是直属于表空间的 FREE 链表的基节点、 FREE_FRAG 链表的基节点、FULL_FRAG 链表的基节点这三个链表的基节点在表空间的位置是固定的就是在表空间的第一个页面也就是 FSP_HDR 类型的页面的 File Space Header 部分。所以之后定位这几个链表就很简单了。FRAG_N_USED 这个字段表明在 FREE_FRAG 链表中已经使用的页面数量方便之后在链表中查找空闲的页面。FREE Limit 我们知道表空间都对应着具体的磁盘文件一开始我们创建表空间的时候对应的磁盘文件中都没有数据所以我们需要对表空间完成一个初始化操作包括为表空间中的区建立 XDES Entry 结构为各个段建立INODE Entry 结构等。我们可以一开始就为表空间申请一个特别大的空间但是实际上有绝大部分的区是空闲的我们可以选择把所有的这些空闲区对应的 XDES Entry 结构加入FREE 链表也可以选择只把一部分的空闲区加入 FREE 链表等啥时候空闲链表中的 XDES Entry 结构对应 的区不够使了再把之前没有加入 FREE 链表的空闲区对应的 XDES Entry 结构加入 FREE 链表目的就是啥时候用到啥时候初始化在Mysql中他们为表空间定义了 FREE Limit 这个字段在该字段表示的页号之前的区都被初始化了之后的区尚未被初始化。Next Unused Segment ID 表中每个索引都对应2个段每个段都有一个唯一的ID那当我们为某个表新创建一个索引的时候就意味着要创建两个新的段。那怎么为这个新创建的段找一个唯一的ID呢在Mysql中提出了这个名叫 NextUnused Segment ID 的字段该字段表明当前表空间中最大的段ID的下一个ID这样在创建新段的时候直接使用这个字段的值就可以了。Space Flags 表空间对于一些布尔类型的属性或者只需要几个比特位表示的属性都放在了这个 Space Flags 中存储虽然它只有4个字节32个比特位大小却存储了很多表空间的属性具体如下
标志名称占用的空间单位bit描述POST_ANTELOPE1表示文件格式是否大于 ANTELOPEZIP_SSIZE4表示压缩页面的大小ATOMIC_BLOBS1表示是否自动把值非常长的字段放到BLOB页里PAGE_SSIZE4页面大小DATA_DIR1表示表空间是否是从默认的数据目录中获取的SHARED1是否为共享表空间TEMPORARY1是否为临时表空间ENCRYPTION1表空间是否加密UNUSED18没有使用到的比特位
注意不同MySQL版本里 SPACE_FLAGS 代表的属性可能有些差异我们这里列举的是5.7版本的。
List Base Node for SEG_INODES_FULL List 和 List Base Node for SEG_INODES_FREE List 每个段对应的 INODE Entry 结构会集中存放到一个类型位 INODE 的页中如果表空间中的段特别多则会有多个 INODE Entry 结构可能一个页放不下这些 INODE 类型的页会组成两种列表 SEG_INODES_FULL 链表该链表中的 INODE 类型的页面都已经被 INODE Entry 结构填充满了没有剩余空间存放额外的 INODE Entry 了。SEG_INODES_FREE 链表该链表中的 INODE 类型的页面都仍有空闲空间来存放 INODE Entry 结构。
XDES Entry部分 XDES Entry 也是在表空间的第一个页面中保存的。我们知道一个 XDES Entry 结构的大小是40字节但是一个页面的大小有限只能存放有限个 XDES Entry 结构所以我们才把256个区划分成一组在每组的第一个页面中存放256个 XDES Entry 结构。可以回看 FSP_HDR 类型页面的示意图 XDES Entry 0 就对应着 extent 0 XDESEntry 1 就对应着 extent 1 … 依此类推 XDES Entry255 就对应着 extent 255 。因为每个区对应的 XDES Entry 结构的地址是固定的所以我们访问这些结构就很容易了。
XDES 类型
每一个 XDES Entry 结构对应表空间的一个区一个 XDES Entry 结构只占用40字节但如果区的数量非常多时一个单独的页可能就不够存放足够多的 XDES Entry 结构所以我们把表空间的区分为了若干个组每组开头的一个页面记录着本组内所有的区对应的 XDES Entry 结构。由于第一个组的第一个页面有些特殊因为它也是整个表空间的第一个页面所以除了记录本组中的所有区对应的 XDES Entry 结构以外还记录着表空间的一些整体属性这个页面的类型就是上面说的 FSP_HDR 类型整个表空间里只有一个这个类型的页面。除去第一个分组以外之后的每个分组的第一个页面只需要记录本组内所有的区对应的 XDES Entry 结构即可不需要再记录表空间的属性了为了和 FSP_HDR 类型做区别我们把之后每个分组的第一个页面的类型定义为 XDES 它的结构和 FSP_HDR 类型类似 与 FSP_HDR 类型的页面对比除了少了 File Space Header 部分之外也就是除了少了记录表空间整体属性的部分之外其余的部分是一样一样的。
BUF_BITMAP类型
对比前边介绍表空间的图每个分组的第二个页面的类型都是 IBUF_BITMAP 这种类型的页里边记录了一些有关Change Buffer 的相关信息。后续详细介绍。
INODE类型
从上面表空间的结构图可以看出第一个分组的第三个页面的类型是 INODE 。我们前边说过 InnoDB中每个索引定义了两个段而且为某些特殊功能定义了些特殊的段。为了方便管理他们又为每个段设计了一个INODE Entry 结构这个结构中记录了关于这个段的相关属性。现在这个 INODE 类型的页就是为了存储 INODE Entry 结构而存在的。如下图 从上图可以看出一个 INODE 类型的页面是由这几部分构成的
名称中文名占用空间大小简单描述File Header文件头部38 字节页的一些通用信息List Node for INODE Page List通用链表节点12 字节存储上一个INODE页面和下一个INODE页面的指针INODE Entry段描述信息16128 字节Empty Space尚未使用空间6 字节用于页结构的填充没啥实际意义File Trailer文件尾部8 字节校验页是否完整
除了 File Header 、 Empty Space 、 File Trailer 这几个之前介绍过我们重点关注 List Node for INODE Page List 和 INODE Entry 这两个部分。首先看 INODE Entry 部分我们前边已经详细介绍过这个结构的组成了主要包括对应的段内零散页面的地址以及附属于该段的 FREE 、 NOT_FULL 和 FULL 链表的基节点。每个 INODE Entry 结构占用192字节一个页面里可 以存储 85 个这样的结构。 重点看一下 List Node for INODE Page List 因为一个表空间中可能存在超过85个段所以可能一个 INODE 类型的页面不足以存储所有的段对应的 INODE Entry 结构所以就需要额外的 INODE 类型的页面来存储这些结构。还是为了方便管理这些 INODE 类型的页面Mysql中将这些 INODE 类型的页面串联成两个不同的链表
SEG_INODES_FULL 链表该链表中的 INODE 类型的页面中已经没有空闲空间来存储额外的 INODE Entry 结构了。SEG_INODES_FREE 链表该链表中的 INODE 类型的页面中还有空闲空间来存储额外的 INODE Entry 结构了。
我们前边提到过这两个链表的基节点就存储在 File Space Header 里边也就是说这两个链表的基节点的位置是固定的所以我们可以很轻松的访问到这两个链表。以后每当我们新创建一个段创建索引时就会创建段时都会创建一个 INODE Entry 结构与之对应存储 INODE Entry 的大致过程如下
先看看 SEG_INODES_FREE 链表是否为空如果不为空直接从该链表中获取一个节点也就相当于获取到一个仍有空闲空间的 INODE 类型的页面然后把该 INODE Entry 结构防到该页面中。当该页面中无剩余空间时就把该页放到 SEG_INODES_FULL 链表中。如果 SEG_INODES_FREE 链表为空则需要从表空间的 FREE_FRAG 链表中申请一个页面修改该页面的类型为 INODE 把该页面放到 SEG_INODES_FREE 链表中与此同时把该 INODE Entry 结构放入该页面。
Segment Header 结构的运用
我们知道一个索引会产生两个段分别是叶子节点段和非叶子节点段而每个段都会对应一个 INODE Entry 结构那我们怎么知道某个段对应哪个 INODE Entry 结构呢所以得找个地方记下来这个对应关系。在前面说过的INDEX 类型的页时有一个 Page Header 部分部分结构如下
名称占用空间大小描述PAGE_BTR_SEG_LEAF10 字节B树叶子段的头部信息仅在B树的根页定义PAGE_BTR_SEG_TOP10 字节B树非叶子段的头部信息仅在B树的根页定义
其中的 PAGE_BTR_SEG_LEAF 和 PAGE_BTR_SEG_TOP 都占用10个字节它们其实对应一个叫 Segment Header 的结 构该结构图示如下 各个部分的具体释义如下
名称占用字节数描述Space ID of the INODE Entry4INODE Entry结构所在的表空间IDPage Number of the INODE Entry4INODE Entry结构所在的页面页号Byte Offset of the INODE Ent2INODE Entry结构在该页面中的偏移量
这样子就很清晰了 PAGE_BTR_SEG_LEAF 记录着叶子节点段对应的 INODE Entry 结构的地址是哪个表空间的哪个页面的哪个偏移量 PAGE_BTR_SEG_TOP 记录着非叶子节点段对应的 INODE Entry 结构的地址是哪个表空间的哪个页面的哪个偏移量。这样子索引和其对应的段的关系就建立起来了。不过需要注意的一点是因为一个索引只对应两个段所以只需要在索引的根页面中记录这两个结构即可。
真实表空间对应的文件大小
我们到数据目录里看一个新建的表对应的 .ibd 文件发现其实只占用了96K才6个页面大小其实是正常的。一开始表空间占用的空间自然是很小因为表里边都没有数据嘛不过这些 .ibd 文件是自扩展的文件随着表中数据的增多表空间对应的文件也逐渐增大。
系统表空间
了解完了独立表空间的基本结构系统表空间的结构也就好理解多了系统表空间的结构和独立表空间基本类似只不过由于整个MySQL进程只有一个系统表空间在系统表空间中会额外记录一些有关整个系统信息的页面所以会比独立表空间多出一些记录这些信息的页面。因为这个系统表空间最牛逼相当于是表空间之首所以它的 表空间 ID Space ID是 0 。
系统表空间的整体结构
系统表空间与独立表空间的一个非常明显的不同之处就是在表空间开头有许多记录整个系统属性的页面如图 可以看到系统表空间和独立表空间的前三个页面页号分别为 0 、 1 、 2 类型分别是 FSP_HDR 、 IBUF_BITMAP 、 INODE 的类型是一致的只是页号为 3 7 的页面是系统表空间特有的我们来看一下这些 多出来的页面的用途
页号页面类型英文描述描述3SYSInsert Buffer Header存储Insert Buffer的头部信息4INDEXInsert Buffer Root存储Insert Buffer的根页面5TRX_SYSTransction System事务系统的相关信息6SYSFirst Rollback Segment第一个回滚段的页面7SYSData Dictionary Header数据字典头部信息
除了这几个记录系统属性的页面之外系统表空间的 extent 1 和 extent 2 这两个区也就是页号从 64 ~ 191这128个页面被称为 Doublewrite buffer 也就是双写缓冲区。这些大部分知识都涉及到了事务和多版本控制的问题这些问题我们在后续再进行分享。
InnoDB数据字典
我们平时使用 INSERT 语句向表中插入的那些记录称之为用户数据MySQL只是作为一个软件来为我们来保管这些数据提供方便的增删改查接口而已。但是每当我们向一个表中插入一条记录的时候MySQL先要校验一下插入语句对应的表存不存在插入的列和表中的列是否符合如果语法没有问题的话还需要知道该表的聚簇索引和所有二级索引对应的根页面是哪个表空间的哪个页面然后把记录插入对应索引的 B 树中。所以说MySQL除了保存着我们插入的用户数据之外还需要保存许多额外的信息比方说
某个表属于哪个表空间表里边有多少列表对应的每一个列的类型是什么该表有多少索引每个索引对应哪几个字段该索引对应的根页面在哪个表空间的哪个页面该表有哪些外键外键对应哪个表的哪些列某个表空间对应文件系统上文件路径是什么等等
上述这些数据并不是我们使用 INSERT 语句插入的用户数据实际上是为了更好的管理我们这些用户数据而不得已引入的一些额外数据这些数据也称为元数据 。InnoDB存储引擎特意定义了一些列的内部系统表internal system table来记录这些这些 元数据
表名描述SYS_TABLES整个InnoDB存储引擎中所有的表的信息SYS_COLUMNS整个InnoDB存储引擎中所有的列的信息SYS_INDEXES整个InnoDB存储引擎中所有的索引的信息SYS_FIELDS整个InnoDB存储引擎中所有的索引对应的列的信息SYS_FOREIGN整个InnoDB存储引擎中所有的外键的信息SYS_FOREIGN_COLS整个InnoDB存储引擎中所有的外键对应列的信息SYS_TABLESPACES整个InnoDB存储引擎中所有的表空间信息SYS_DATAFILES整个InnoDB存储引擎中所有的表空间对应文件系统的文件路径信息SYS_VIRTUAL整个InnoDB存储引擎中所有的虚拟生成列的信息
这些系统表也被称为数据字典 它们都是以 B 树的形式保存在系统表空间的某些页面中其中SYS_TABLES 、 SYS_COLUMNS 、 SYS_INDEXES 、 SYS_FIELDS 这四个表尤其重要称之为基本系统表basic system tables我们先看看这4个表的结构
SYS_TABLES表
mysql show create table information_schema.INNODB_SYS_TABLES ;注意不同版本的字段可能有所差异。
列名描述TABLE_IDInnoDB存储引擎中每个表都有一个唯一的IDNAME表的名称FLAG有关表格式和存储特性的位级信息数据N_COLS该表拥有列的个数SPACE该表所属表空间的IDFILE_FORMAT表空间文件的存储格式ROW_FORMAT行格式ZIP_PAGE_SIZE压缩页大小SPACE_TYPE表的类型记录了一些文件格式、行格式、压缩等信息
SYS_COLUMNS表
mysql show create table information_schema.INNODB_SYS_COLUMNS;列名描述TABLE_ID该列所属表对应的IDNAME该列的名称POS该列在表中是第几列MTYPEmain data type主数据类型就是那堆INT、CHAR、V ARCHAR、FLOA T、DOUBLE之类的东东PRTYPEprecise type精确数据类型就是修饰主数据类型的那堆东东比如是否允许NULL值是否允许负数啥的LEN该列最多占用存储空间的字节数
SYS_INDEXES表
列名描述INDEX_ID索引 IDNAME该索引的名称TABLE_ID该索引所属表对应的IDID InnoDB存储引擎中每个索引都有一个唯一的IDN_FIELDS该索引包含列的个数TYPE该索引的类型比如聚簇索引、唯一索引、更改缓冲区的索引、全文索引、普通的二级索引等等各种类型SPACE该索引根页面所在的表空间IDPAGE_NO该索引根页面所在的页面号MERGE_THRESHOLD如果页面中的记录被删除到某个比例就把该页面和相邻页面合并这个值就是这个比例
SYS_FIELDS表
列名描述INDEX_ID该索引列所属的索引的IDNAME该索引列的名称POS该索引列在某个索引中是第几列
Data Dictionary Header页面 只要有了上述4个基本系统表也就意味着可以获取其他系统表以及用户定义的表的所有元数据。比方说我们想看看 SYS_TABLESPACES 这个系统表里存储了哪些表空间以及表空间对应的属性那就可以
到 SYS_TABLES 表中根据表名定位到具体的记录就可以获取到 SYS_TABLESPACES 表的 TABLE_ID使用这个 TABLE_ID 到 SYS_COLUMNS 表中就可以获取到属于该表的所有列的信息。使用这个 TABLE_ID 还可以到 SYS_INDEXES 表中获取所有的索引的信息索引的信息中包括对应的INDEX_ID 还记录着该索引对应的 B 数根页面是哪个表空间的哪个页面。使用 INDEX_ID 就可以到 SYS_FIELDS 表中获取所有索引列的信息。
也就是说这4个表是表中之表那这4个表的元数据去哪里获取呢没法搞了只能把这4个表的元数据就是它们有哪些列、哪些索引等信息硬编码到代码中然后 在InnoDB 中又拿出一个固定的页面来记录这4个表的聚簇索引和二级索引对应的 B树 位置这个页面就是页号为 7 的页面类型为 SYS 记录了 Data DictionaryHeader 也就是数据字典的头部信息。除了这4个表的5个索引的根页面信息外这个页号为 7 的页面还记录了整个InnoDB存储引擎的一些全局属性这个页面的示意图如下 可以看到这个页面由下边几个部分组成
名称中文名占用空间大小简单描述File Header文件头部38 字节页的一些通用信息Data Dictionary Header数据字典头部信息56 字节记录一些基本系统表的根页面位置以及InnoDB存储引擎的一些全局信息Segment Header段头部信息 10 字节 记录本页面所在段对应的INODE Entry位置信息Empty Space尚未使用空间16272 字节用于页结构的填充没啥实际意义File Trailer文件尾部8 字节校验页是否完整
可以看到这个页面里有 Segment Header 部分意味着Innodb中把这些有关数据字典的信息当成一个段来分配存储空间我们就暂且称之为数据字典段吧。由于目前我们需要记录的数据字典信息非常少可以看到 Data Dictionary Header 部分仅占用了56字节所以该段只有一个碎片页也就是页号为 7 的这个页。 接下来我们需要看一下 Data Dictionary Header 部分的各个字段
Max Row ID 我们说过如果我们不显式的为表定义主键而且表中也没有 UNIQUE 索引那么 InnoDB 存储引擎会默认为我们生成一个名为 row_id 的列作为主键。因为它是主键所以每条记录的 row_id 列的值不能重复。原则上只要一个表中的 row_id 列不重复就可以了也就是说表a和表b拥有一样的 row_id 列也没啥关系不过InnoDB中只提供了这个 Max Row ID 字段不论哪个拥有 row_id 列的表插入一条记录时该记录的 row_id 列的值就是 Max Row ID 对应的值然后再把 Max Row ID 对应的值加1也就是说这个 Max Row ID 是全局共享的。Max Table ID InnoDB存储引擎中的所有的表都对应一个唯一的ID每次新建一个表时就会把本字段的值作为该表的ID然后自增本字段的值。Max Index ID InnoDB存储引擎中的所有的索引都对应一个唯一的ID每次新建一个索引时就会把本字段的值作为该索引的ID然后自增本字段的值。Max Space ID InnoDB存储引擎中的所有的表空间都对应一个唯一的ID每次新建一个表空间时就会把本字段的值作为该表空间的ID然后自增本字段的值。Mix ID Low(Unused) 这个字段没啥用跳过。Root of SYS_TABLES clust index 本字段代表 SYS_TABLES 表聚簇索引的根页面的页号。Root of SYS_TABLE_IDS sec index 本字段代表 SYS_TABLES 表为 ID 列建立的二级索引的根页面的页 号。Root of SYS_COLUMNS clust index 本字段代表 SYS_COLUMNS 表聚簇索引的根页面的页号。Root of SYS_INDEXES clust index 本字段代表 SYS_INDEXES 表聚簇索引的根页面的页号。Root of SYS_FIELDS clust index 本字段代表 SYS_FIELDS 表聚簇索引的根页面的页号。Unused 这4个字节没用跳过。
information_schema系统数据库 需要注意一点的是用户是不能直接访问 InnoDB 的这些内部系统表的除非你直接去解析系统表空间对应文件 系统上的文件。但是InnoDB中考虑到查看这些表的内容可能有助于大家分析问题所以在系统数据库information_schema 中提供了一些以 innodb_sys 开头的表。
mysql use information_schema;
Database changed
mysql show tables like INNODB_SYS%;
--------------------------------------------
| Tables_in_information_schema (INNODB_SYS%) |
--------------------------------------------
| INNODB_SYS_DATAFILES |
| INNODB_SYS_VIRTUAL |
| INNODB_SYS_INDEXES |
| INNODB_SYS_TABLES |
| INNODB_SYS_FIELDS |
| INNODB_SYS_TABLESPACES |
| INNODB_SYS_FOREIGN_COLS |
| INNODB_SYS_COLUMNS |
| INNODB_SYS_FOREIGN |
| INNODB_SYS_TABLESTATS |
--------------------------------------------
10 rows in set (0.00 sec)在 information_schema 数据库中的这些以 INNODB_SYS 开头的表并不是真正的内部系统表内部系统表就是我们上面说的以 SYS 开头的那些表而是在存储引擎启动时读取这些以 SYS 开头的系统表然后填充到这些以INNODB_SYS 开头的表中。以 INNODB_SYS 开头的表和以 SYS 开头的表中的字段并不完全一样但可供参考。
更多关于mysql的知识分享请前往博客主页。编写过程中难免出现差错敬请指出
