网络营销基础 网站策划与网上营销,做网批有专门的网站吗,游戏行业seo整站优化,ps怎么做华为网站界面文章目录 一、概念引入1、页2、区3、段 二、页的结构1、File Header2、FIle Trailer 三、区的结构1、分类2、XDES Entry3、XDES Entry链表 四、段的结构五、独立表空间1、FSP_HDR页2、XDES页3、IBUF_BITMAP页4、INODE页5、INDEX页 六、系统表空间 一、概念引入
1、页
InnoDB是… 文章目录 一、概念引入1、页2、区3、段 二、页的结构1、File Header2、FIle Trailer 三、区的结构1、分类2、XDES Entry3、XDES Entry链表 四、段的结构五、独立表空间1、FSP_HDR页2、XDES页3、IBUF_BITMAP页4、INODE页5、INDEX页 六、系统表空间 一、概念引入
1、页
InnoDB是以页为单位管理存储空间的在InnoDB中针对不同的目的设计了各种不同类型的页面。如下省略了FIL_PAGE或FiL_PAGE_TYPE的前缀
ALLOCATED最新分配还未使用UNDO_LOGundo日志页INODE用于存储段的信息IBUF_FREE_LISTChange Buffer空闲列表IBUF_BITMAPChange Buffer的一些属性SYS存储一些系统数据TRX_SYS事务系统数据FSP_HDR表空间头部信息XDES用于存储区的一些属性BLOB溢出页INDEX索引页/数据页我们的聚簇索引和其他的二级索引都是以B树的形式保存到表空间而B树的节点就是索引页/数据页
2、区
**区是由连续页组成的空间在任何情况下每个区的大小都为1MB。**无论是系统表空间还是独立表空间都可以看成是由若干个连续的区组成的。
区是用于向磁盘申请存储空间的单位。之所以引入区的概念是因为如果以页尾单位来分配存储空间双向链表B树每一层的页都会形成一个双向链表相邻的两个页的物理位置可能离的非常远。为了尽量让页面链表中相邻的页的物理位置也相邻使得每次扫描节点中的记录时可以使用顺序IO所以每次会申请一块更大的存储空间即区之后页从区中分配而不是每次都以单独的页去申请。
3、段
InnoDB中在区之上又引入了段的概念段其实不对应表空间中某一个连续的物理区域它是一个逻辑上的概念由若干个零散的页面和一些完整的区组成。实际上就是对表空间中的页进行分类将存放相同类型数据的页统筹到一起进行管理例如undo页便组成了回滚段。此外每个索引也按照B树的叶子结点和非叶子节点进行区别对待也就是说叶子节点有自己独有的区非叶子节点也有自己独有的区。存放叶子节点的区的集合就算是一个段存放非叶子结点的区的集合也是一个段。也就是说一个索引会生成两个段一个叶子结点段和一个非叶子节点段。
由于一个区默认是占用1MB的存储空间对于存储记录比较少的表而言也许根本用不完这么多的空间。为了节省空间InnoDB引入了碎片区的概念在一个碎片区中并不是所有的页都是为了存储同一个段的数据而存在的碎片区中的页可以用于不同的目的有些属于段A、有些属于段B有些甚至不属于任何段。碎片区直属于表空间并不属于任何一个段。
段进行空间分配的策略如下
刚开始向表中插入数据时段是从某个碎片区以单个页面为单位来分配存储空间的当某个段已经占用了32个碎片区页面之后就会以完整的区为单位来分配存储空间原本占用的碎片区页面不会复制到新申请的完整的区中
这也就是最开始所说的段由若干个零散的页面和一些完整的区组成。
二、页的结构
InnoDB中的页有两个固定的部分
File Header38 字节文件头File Trailer8 字节文件结尾信息
File Header和File Trailer中间的部分根据类型的不同有着不同的结构而这两个部分是所有页面统一的。
1、File Header
File Header 是用来记录各种页都适用的一些通用信息由8个部分组成
FIL_PAGE_SPACE_OR_CHKSUM当前页面的校验和FIL_PAGE_OFFSET页号FIL_PAGE_PREV上一个页的页号FIL_PAGE_NEXT下一个页的页号FIL_PAGE_LSN该页最后被修改的日志序列位置FIL_PAGE_TYPE页的类型FIL_PAGE_FILE_FLUSH_LSN仅在系统表空间的一个页中定义代表文件至少被更新到了该LSN值。对于独立表空间该值都为0FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID页属于哪个表空间
表空间中的每一个页都对应着一个页号表空间中第一个页的页号为0之后的也好分别是1、2、3等。某些类型的页可以通过FIL_PAGE_PREV和FIL_PAGE_NEXT组成链表主要用于索引页/数据页B树的特性决定的链表中相邻的两个页面的页号可以不连续。
2、FIle Trailer
File Trailer用于校验是否完整保证页面从内存刷新到磁盘后内容是相同的由2个部分组成
校验和与FIle Header中的校验和相对应LSN与File Heder中的LSN相对应
如果页面刷新成功则页首和页尾的校验和以及LSN应该是一致的。如果刷新了一部分后断电了那么头部的校验和就代表着已经修改过的页而尾部的校验和代表着原先的页两者不同则说面刷新期间发生了错误。
三、区的结构
1、分类
FREE空闲的区。现在还没有用到这个区中的任何页面FREE_FRAG有剩余空闲页面的碎片区。表示碎片区中还有可分配的空闲页面FULL_FRAG没有剩余空闲页面的碎片区。表示碎片区中的所有页面都被分配使用没有空闲页面FSEG附属于某个段的区。区别于碎片区这些区中的页面完全用于存储该段中的数据
FREE、FREE_FRAG、FULL_FRAG这3种状态的区都是独立的算是直属于表空间而处于FSEG状态的区是附属于某个段的。
2、XDES Entry
为了方便管理这些区InnoDB中有一个称为XDES Entry的结构。每一个区都对应着一个XDES Entry结构这个结构记录了对应的区的一些属性。
XDES Entry结构有40字节大致分为4个部分 Segment ID8字节每一个段都有一个唯一的编号标志当前区是分配给哪个段的 List Node12字节这个部分可以将若干个XDES Entry结构串成一个链表 Prev Node Page Number和Prev Node Offset指向前一个XDES Entry的指针Next Node Page Number和Next Node Offsett指向下一个XDES Entry的指针 State4字节表名区的状态即前面提到的FREE、FREE_FRAG、FULL_FRAG和FSEG Page State Bitmap16字节划分为64个部分每个部分有2位对应区中的一个页。其中第一位表示对应的页是否空闲第二位还没有用到
3、XDES Entry链表
当段中数据较少时首先会查看表空间中是否有状态为FREE_FRAG的区也就是查找还有空闲页面的碎片区如果没有则到表空间中申请一个状态为FREE的区把该区的状态变为FREE_FRAG然后从中取一个零散页把数据插进去如果段中的数据已经占满了32个零散的页则申请完整的区来插入
由于表空间是可以不断增大的不可能每次查找区的的时候都去遍历整个表所有区的XDES Entry。所以对于直属于表空间的三种类型的区使用List Node维护了对应的三种类型FREE、FREE_FRAG、FULL_FRAG的链表来方便查找之后使用时直接从对应的链表的头结点取即可。对于直属于段的区也维护了三种类型FREE、NOT_FULL、FULL的链表。 如果一个表有两个索引那么将会有4个段。对于每个段都需要维护三种类型的链表再加上直属于表空间的3个链表总共需要维护15个类型的链表。 使用链表可以将不同类型的区给区分出来那我们首先还需要找到链表的头结点才可以使用。因此前面介绍的**每个链表都会对应有一个List Base Node结构这个结构中包含了链表的头节点和尾节点的指针和这个链表包含了多少个节点的信息。**List Base Node结构会放置在表空间中的一个固定位置那么要查找某种类型的区时就直接去这个固定的位置拿到List Base Node然后拿到它的头节点即可。
四、段的结构
像每个区都有一个对应的的XDES Entry结构一样每个段也都定义了一个INDOE Entry结构来记录段中的信息。INODE Entry的属性如下
Segment ID这个结构对应的段的编号NOT_FULL_N_USED在NOT_FULL链表中已经使用了多少个页面3个List Base Node前面提到的每个段都会维护有直属于段的三个链表INODE Entry中则存放了这三个链表的List Base Node结构Magic Number标记段是否已经被初始化Fragment Array Entry前面三个链表中维护的都是完整的区而段中还会有一些从碎片区申请的零碎的页它们的页号则存放在这里
五、独立表空间 在MySQL5.6.6及以后的版本中**InnoDB不再默认把各个表的数据存储到系统表空间而是为每个表建立一个独立表空间。**也就是创建了多少个表就有多少个独立表空间。在使用独立表空间来存储数据时会在该表所属数据库对应的子目录下创建一个表示该独立表空间的文件其文件名和表名相同文件后缀为.ibd。 前面我们讲到了区和段的概念也讲到了它们对应的XDES Entry结构和INODE Entry结构以及各种以XDES Entry为节点的链表。我们知道了页的申请需要用到这些结构那这些结构存放在那呢这就需要了解整个表空间的结构了。
表空间实际上就是由许许多多的页组成的为了更好的管理页我们引入了区的概念对于16KB的页而言64个连续的页面就是一个区。而表空间可以看为是由若干个连续的区组成其中每256个区被划分成了一组同样是为了更好的管理每个组中的前几个页面会负责维护这个组的一些信息。 第一个组最开始的三个页面的类型是固定的 FSP_HDR用来登记整个表空间的一些整体属性以及本组256个区的属性一个表空间只有一个FSP_HDR页IBUF_BITMAP存储关于Change Buffer的一些信息INODE存储了整个表中所有段的INODE Entry 其余所有组的前两个页面的类型是固定的 XDES登记本组256个区的属性IBUF_BITMAP存储关于Change Buffer的一些信息
1、FSP_HDR页
这是表空间的第一个页面页号为0类型为FSP_HDR其组成如下 FIle Header页的通用结构不再赘述 File Space Header表空间头部用来描述表空间的一些整体属性信息 表空间ID 表空间拥有的页面数 尚未被初始化的最小页号大于或等于这个页号的区对那个的XDES Entry结构都没有被加入FREE链表对于表空间而言可能在初始化或者自增长时分配的磁盘空间很大而这些磁盘空间的空闲区并没有直接加入到FREE链表而是等到需要使用时在初始化加入到FREE链表中 FREE_FRAG链表中已使用的页面数量 FREE、FREE_FRAG、FULL_FRAG链表的基节点 表空间中下一个未使用的段ID每次创建新段时从这里获取ID使用后将该值加一即可 SEG_INODES_FULL和SEG_INODES_FREE链表的基节点 每个段对应的INODE Entry结构会集中存放到一个类型为INODE的页前面也提到了第一个组的第三个页面就是INODE类型的页其中就会存放表空间的所有INODE Entry如果表空间的段特别多那么就会有多个INODE Entry结构需要多个页面进行存放因此使用这两个链表来标记已经存满的INODE页和仍有空间的INODE页 XDES Entry区描述信息存储本组256个区对应的属性信息 这就是我们前面提到的每个区对应的结构它们便存放此处。一个XDES Entry是40个字节每个组中维护了256个区那么在此处存放在每个组的第一个页面这里是第一个组页面类型是FSP_HDR除了存放XDES Entry还存放了表空间的信息后面所有组第一个页面都是XDES类型显然不难看出就是专门用于存放XDES Entry的就会存放256个XDES Entry结构因为每个区对应的XDES Entry结构的地址是固定的因此就可以很方便的找到区对应的XDES Entry Empty Space尚未使用的空间 File Trailer页的通用结构不再赘述
2、XDES页
除了第一个组其余每组第一个页面都是XDES类型的页面其中存放了这个组内所有区对应的XDES Entry。
与FSP_HDR类型的页面相比XDES类型的页面除了没有File Space Header部分之外其余部分都是一样的。
3、IBUF_BITMAP页
每个分组的第二个页面的类型都是IBUF_BITMAP这种类型的页面中记录了一些有关Change Buffer的信息。
我们平时向表中插入一条记录实际本质就是向每个索引对应的B树插入记录。该记录首先插入聚簇索引页面然后再插入每个二级索引页面。这些页面在表空间中随机分布将会产生大量的随机I/O严重影响性能修改和删除也是同理。因此InnoDB引入了Change BUffer结构本质上也是表空间中的一棵B树它的根节点存储在了系统表空间中在修改非唯一二级索引页面时原因可以自行了解关于Change Buffer的内容如果该页面尚未被加载到内存中那么该修改将先被暂时缓存到Change Buffer中之后服务器空闲或者因为其他原因导致对应的页面加载到内存时再将修改合并到对应页面。
4、INODE页
**第一个分组中的第三个页面的类型是INODE前面提到的每个段对应的INODE Entry便存放在这个页中。**其组成如下
File Header页的通用结构不再赘述List Node for INODE Page List通用链表节点存储上一个INODE页面和下一个INODE页面的指针。就是前面FSP_HDR页面中提到的SEG_INODES_FULL链表和SEG_INODES_FREE链表节点INODE Entry段描述信息一个INODE Entry结构占192字节一个页面中可以存储85个这样的结构Empty Space尚未使用的空间File Trailer页的通用结构不再赘述
当我们每创建一个新的段时创建索引就会创建段都会创建一个与之对应的INODE Entry其流程如下
查看SEG_INODES_FREE链表是否为空如果不为空则直接从链表中获取一个节点。即获取到一个仍有空闲空间的INODE类型的页面然后把该INODE Entry结构放到该页面中。当该页面中无剩余空间时就把页放到SEG_INODES_FULL链表中如果SEG_INODES_FREE链表为空则需要从表空间的FREE_FRAG链表中申请一个页面并将该页面的类型修改为INODE把该页面放到SEG_INODES_FREE链表中同时把该INODE Entry结构放入页面
5、INDEX页
表空间中除了前面提到的每个组前几个固定的页面剩下大多数存放的都是INDEX页也就是B树的节点。我们知道B树中叶子节点存放的是数据而非叶子节点存放的是索引。但其实无论是聚簇索引还是二级索引无论是叶子节点还是非叶子节点都是使用这个类型的页面。其结构如下 File Header页的通用结构不再赘述数据页之间没有必要是物理连续的因为这个头部中有双向链表来维护页的顺序 Page Header PAGE_N_DIR_SLOTS在Page Directory页目录中的slot槽数PAGE_HEAP_TOP堆中第一个记录的指针记录在页中是根据堆的形式存放的PAGE_N_HEAP堆中的记录数占用两个字节最高位表示是否为紧凑型记录PAGE_FREE指向可重用空间的首指针PAGE_GARBAGE已删除记录的字节数即行记录结构中 delete flag 为 1 的记录大小的总数PAGE_LAST_INSET最后插入记录的位置PAGE_DIRECTION最后插入的方向PAGE_LEFT、PAGE_RIGHT等PAGE_N_DIRECTION一个方向连续插入记录的数量PAGE_N_RECS该页中记录的数量不包括最小和最大记录以及标记为删除的记录PAGE_MAX_TRX_ID当前页最大事务 ID该值仅在 Secondary Index 定义PAGE_LEVEL当前页在索引树中的位置叶节点总是在第0层PAGE_INDEX_ID索引ID表示当前页属于哪个索引PAGE_BTR_SEG_LEAFB 树数据页非叶节点所在段的segment header该值仅在B树的Root页中定义PAGE_BTR_SEG_TOPB 树数据页所在段的segment header该值仅在B树的Root页中定义 Infimum 和 Supremum Records最小记录和最大记录两个虚拟的记录 在 InnoDB 存储引擎中每个数据页中共有两个虚拟的行记录用来限定记录的边界Infimum 记录是比该页中任何主键值都要小的值Supremum 指比任何可能大的值还要大的值这两个值在页创建时被建立并且在任何情况下不会被删除记录比大小是通过主键值进行比较。虽然Infimum和Supremum没有主键值但是默认Infimum就是最小记录Supremum就是最大记录 User Record实际存储行记录的内容 对于叶子节点而言这里其实就是数据表中每一行的数据对于非叶子节点也就是索引而言这里存放的其实也是一行一行的数据不过行的构成是索引的值和其指向的页面的页号 Free Space空闲空间同样也是个链表数据结构。在一条记录被删除之后该空间会被加入到空闲链表中 Page Directory页目录 将所有正常的记录包括Infimum和Supremum记录但不包括移除到垃圾链表的记录划分为几个组每组的最后一条记录组内最大的那条记录的头信息中的n_owned属性表示该组内共有几条记录将每个组最后一条记录在页面中的地址偏移量单独提取出来按顺序存放。页目录中的这些地址偏移量称为槽InnoDB存储引擎的槽是一个稀疏目录一个槽中可能包含多个记录。伪记录Infimum的n_owned值总是为1Supremum的n_owned的取值范围为[1, 8]其他用户记录n_owned的取值范围为 [4,8]。当记录被插入或删除时需要对槽进行分裂或平衡的维护操作B树索引本身并不能找到具体的一条记录能找到的只是该记录所在的页。数据库把页载入到内存然后通过Page Directory再进行二叉查找找到具体的槽分组之后进入到分组中遍历槽内的记录 File Trailer页的通用结构不再赘述
我们都知道一个索引会产生两个段分别是叶子节点段和非叶子节点段而每个段都会对应一个INODE Entry结构。那我们怎么知道某个段对应哪个INODE Entry结构呢**其实索引对应的段的INODE Entry结构就存放在这个索引INDEX页面的Page Header中的Page_BTR_SEG_LEAFB树叶子节点段的头部信息和PAGE_BTR_SEG_TOPB树非叶子段的头部信息属性中只会在B树的根页中定义。**这两个属性其实都对应一个Segment Header的结构具体结构如下
Space ID of the INODE EntryINODE Entry结构所在的表空间IDPage Number of the INDOE EntryINODE Entry结构所在的页面页号Byte Offset of the INODE EntryINODE Entry结构在该页面中的偏移量 行记录的记录头信息固定占用 5 个字节40 位 预留位1位 预留位1位 deleted_flag1位该行是否已被删除 记录删除之后并不会从磁盘移除因为移除还需要在磁盘上重新排列其他的记录所以只将其标记为1被删除掉的记录会形成一个垃圾链表记录在这个链表中占用的空间称为可重用空间 min_rec_flag1位B 树每层非叶子节点中最小的目录项记录都会添加该标记 n_owned4位每个页的记录会被分组分组的owner组内最大记录会记录该组的记录数量 heap_no13位索引堆中该条记录的排序记录 向表中插入的记录本质上来说都是放到User Records部分这些记录一条一条紧密的排列在一起把每一条记录包括deleted_flag为1的记录在堆中的相对位置称之为heap_no。在页中靠前的记录heap_no相对较小靠后的记录heap_no相对较大。每申请一条新的记录的存储空间时该记录比物理位置在它前面的那条记录的heap_no值大一 record_type3位0表示普通记录1表示非叶子节点的目录项记录即索引2表示Infimum记录3表示Supremum记录 next_record16位下一条记录的相对位置 下一跳记录指的并不是插入顺序中的下一条而是按照主键值有小到大的顺序排列的下一条记录InnoDB始终会维护记录的一个单项链表链表中的各个节点都是按照主键值从小到大的顺序连接起来的目录项中的槽就是按照链表的顺序划分的从而保证一个有序性被删除的记录也会使用该属性连接形成垃圾链表 对于普通记录叶子结点和目录项记录非叶子结点/索引都是采用一样的行记录格式只有如下部分有所差别 目录项的record_type是1普通记录是0目录项记录只有主键值和页号两个列二级索引有3个列索引列的值、主键值和页号先按照索引列排序之后在按照主键值排序而普通记录的列是用户自己定义的可能包含很多了还有InnoDB自己添加的隐藏列只有目录项记录的min_rec_flag属性才可能为1普通记录的都是0 六、系统表空间 在默认情况下InnoDB会在数据目录下创建一个名为ibdata1、大小为12MB的文件这个文件就是系统表空间在文件系统上的表示。这个文件是一个字扩展文件当不够用时会自动自己增加文件大小。 前面我们知道了每个独立表空间中都划分成了一些组每个组包含了256个区组的前几个页面为保存有区对应的XDES Entry结构而表空间的第一个页面还存放了直属于表空间的各种类型的区的链表以及表中各个段对应的INODE Entry结构。那么此时我们如果在添加数据时需要申请页面就可以根据当前所操作的这棵B树找到其对应的段的INODE Entry如果其维护的零碎的页面还没有超过32个那么就会从直属于表空间的区的链表中找到合适的区去申请页面。如果已经超过了那么就从直属于这个段的区的链表中找到合适的区申请页面。
前面操作的前提都是我们需要能拿到我们要操作的B树的根节点那怎么找到要插入的数据所在的B树呢。在独立表空间中其实并没有维护哪个索引就是对应哪个数据页之类的信息这部分信息是存储在系统表空间中的。
系统表空间和独立表空间的前三个页面的类型是一致的FSP_HDR、XDES、IBUF_BITMAP后续其他组的前两个页面类型也是一致的XDES、IBUF_BITMAP。但是页号3-7的页面即第一个组的第四到第八个页面是系统表空间特有的如下
页号3SYSInsert Buffer Header存放Change Buffer的头部信息页号4INDEXInsert Buffer Root存放Change Buffer的根页面页号5TRX_SYSTransaction System事务系统的相关信息页号6SYSFirst Rollback Segment第一个回滚段的信息页号7SYSData Dictionary Header数据字典头部信息
除了这几个记录系统属性的页面外系统表空间第二个区和第三个区即extent1和exten2也就是页号从64-191这128个页面称为Doublewrite Buffer双写缓冲区。
为了解决我们上面提到的问题这里我们主要了解数据字典。
当我们向一个表中插入一条记录时MySQL先要校验插入语句所对应的表是否存在以及插入的列和表中的列是否符合如果语法没有问题还需要知道表的聚簇索引和所有二级索引对应的根页面是哪个表空间的哪个页面然后再把记录插入到对应索引的B树中。所以我们除了在独立表空间中保存用户插入的数据外还需要在系统表空间中保存许多额外的信息
某个表属于哪个表空间表中有多少列表对应的每一个列的类型是什么该表有多少个索引每个索引对应哪些字段该索引对应的根页面在表空间的哪个页面该表有那些外键对应哪些列某个表空间对应的文件系统上的文件路径是什么
上面这些信息并不是使用iinsert语句插入的用户数据而是为了更好地管理用户数据而不得不引入的一些额外数据也称为元数据。InnoDB存储引擎特意定义了一系列的内部系统表来记录这些元数据具体如下 SYS_TABLES整个InnoDB存储引擎中所有表的信息 表的名称表的ID表的列数表的类型记录了一些文件格式、行格式、压缩等信息表的一些额外属性表所属表空间的ID SYS_COLUMNS整个InnoDB存储引擎中所有列的信息 所属表的ID列在表中是第几列列的名称列的类型精确数据类型修饰主数据类型如是否允许NULL、是否允许负数列最多占用字节数列的精度 SYS_INDEXES整个InnoDB存储引擎中所有索引的信息 所属表的ID索引的ID在InnoDB存储引擎中每个索引都有一个唯一的ID索引名称索引包含列数索引的类型索引根页面所在表空间的ID索引跟页面所在的页面号页面记录被删除到某个比例时尝试与邻居页面合并 SYS_FIELDS整个InnoDB存储引擎中所有索引对应的列的信息 列所属索引ID列在索引列中是第几列列的名称 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这四个表尤为重要称为基本系统表。
只要有了上述4个基本系统表就可以获取其他系统表以及用户定义的表的所有元数据。也就是说这4个表示表中之表。
那么这四个表的元数据比如说它们有哪些页那些索引等信息去哪获取呢这里只能硬编码到代码中了然后将前面讲到的系统表空间的页号为7的页面即Data Dictionary Header用来保存数据字典头部信息。这个页中记录了这4个基本系统表的聚簇索引和二级索引对应的B树的位置以及一些全局属性具体如下 File Header页的通用结构不再赘述 Data Dictionary Header数据字典头部记录一些基本系统表的根位置以及InnoDB存储引擎的一些全局信息 Max Row ID隐藏列row_id的值全局共享的 无论哪个拥有row_id列的表插入一条记录该记录的row_id列的值就是Max Row ID对应的值然后再把Max Row ID对应的值加一 Max Table ID新建表时使用的ID全局共享的 Max Index ID新建索引时使用的ID全局共享的 Max Space ID新建表空间时使用的ID全局共享的 SYS_TABLES表聚簇索引的根页面的页号 SYS_TABLES表二级索引的根页面的页号 SYS_COLUMS表聚簇索引的根页面的页号 SYS_INDEXES表聚簇索引的根页面的页号 SYS_FIELDS表聚簇索引的根页面的页号 Unused未使用 Segment Header段头部记录了本页面所在段对应的INODE Entry位置信息 InnoDB把有关数据字典的信息当成一个段来分配存储空间但是该段要记录的字典信息非常少所以只用到了这一个碎片页 Empty Space尚未使用的空间 File Trailer页的通用结构不再赘述
用户其实不能直接访问InnoDB的这些内部系统表除非直接去解析系统表空间对应的文件系统的文件不过InnoDB在系统数据库information_schema提供了一些以INNODB_SYS开头的表以供访问。这些INNODB_SYS开头的表并非真正的内部系统表而是存储引擎启动时读取系统表后填充进去的所以它们与系统表的字段并不完全一样。
