0基础学MySQL数据库—从小白到大牛(26)InnoDB数据存储结构

前言

本章使用的测试数据库为GreatSQL8.0.25版本

(Wed Aug  3 16:17:03 2022)[root@GreatSQL][(none)]>select version();+-----------+| version() |+-----------+| 8.0.25-16 |+-----------+1 row in set (0.00 sec)

一、数据库的存储结构:页

索引结构给我们提供了高效的索引方式，不过索引信息以及数据记录都是保存在文件上的，确切说是存储在页结构中。另一方面，索引是在存储引擎中实现的，MySQL服务器上的存储引擎负责对表中数据的读取和写入工作。不同存储引擎中存放的格式一般是不同的，甚至有的存储引擎比如Memory都不用磁盘来存储数据。

磁盘与内存交互基本单位:页

数据库读写磁盘的基本单位是页（Page），数据库，无论是读一行，还是读取多行，都是将这些行所在的页进行加载。

InnoDB将数据划分为若干个页，InnoDB中页的大小默认为16KB

以页作为磁盘和内存之间交互的基本单位，也就是一次最少从磁盘中读取16KB的内容到内存中，一次最少把内存中的16KB内容刷新到磁盘中。也就是说，在数据库中，不论读一行，还是读多行，都是将这些行所在的页进行加载。也就是说，数据库管理存储空间的基本单位是页(Page)，数据库I/O操作的最小单位是页一个页中可以存储多个行记录
记录是按照行来存储的，但是数据库的读取并不以行为单位，否则一次读取（也就是一次I/O操作)只能处理一行数据，效率会非常低。

页结构概述

页a、页b、页c …页n这些页可以不在物理结构上相连，只要通过双向链表相关联即可。每个数据页中的记录会按照主键值从小到大的顺序组成一个单向链表，每个数据页都会为存储在它里边的记录生成一个页目录，在通过主键查找某条记录的时候可以在页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录。

页的大小

不同的数据库管理系统（简称DBMS）的页大小不同。比如在MySQL的InnoDB存储引擎中，默认页的大小是16KB，可以通过下面的命令来进行查看:

(Tue Aug  9 15:25:48 2022)[root@GreatSQL][(none)]>show variables like '%innodb_page_size%';+------------------+-------+| Variable_name    | Value |+------------------+-------+| innodb_page_size | 16384 |+------------------+-------+1 row in set (0.00 sec)

SQL Server中页的大小为 8KB，而在oracle中用术语’'块’’(Block)来代表"页”，Oralce支持的块大小为2KB，4KB，8KB，16K8，32KB和64KB。

页的上层结构

**区(Extent)**是比页大一级的存储结构，在InnoDB存储引擎中，一个区会分配64个连续的页。因为InnoDB中的页大小默认是16KB，所以一个区的大小是64*16KB= 1MB。

**段(Segment)**由一个或多个区组成，区在文件系统是一个连续分配的空间（在InnoDB中是连续的64个页)，不过在段中不要求区与区之间是相邻的。段是数据库中的分配单位，不同类型的数据库对象以不同的段形式存在。 当创建数据表、索引的时候，就会相应创建对应的段，比如创建一张表时会创建一个表段，创建一个索引时会创建一个索引段。

**表空间（Tablespace)**是一个逻辑容器，表空间存储的对象是段，在一个表空间中可以有一个或多个段，但是一个段只能属于一个表空间。数据库由一个或多个表空间组成，表空间从管理上可以划分为系统表空间，用户表空间、撤销表空间、临时表空间等。

二、页的内部结构

页如果按类型划分的话，常见的有数据页（保存B+树节点）、系统页、Undo页和事务数据页等。数据页是我们最常使用的页。

数据页的16KB大小的存储空间被划分为七个部分，分别是文件头(File Header)、页头(Page Header)、最大最小记录(Infimum+supremum)、用户记录(User Records)、空闲空间(Free Space)、页目录(Page Directory)和文件尾(File Tailer) 。

页结构的示意图如下所示:

这7个部分作用分别如下，简单梳理如下表所示:

名称	占用大小	说明
File Header	38字节	文件头，描述页的信息
Page Header	56字节	页头,页的状态信息
lnfimum-Supremum	26字节	最大和最小记录，这是两个虚拟的行记录
User Records	不确定	用户记录，存储行记录内容
Free Space	不确定	空闲记录，页中还没有被使用的空间
Page Directory	不确定	页目录，存储用户记录的相对位置
File Trailer	8字节	文件尾,校验页是否完整

我们可以把7个结构分成三个部分

第一部分：File Header（头部文件）和File Trailer（文件尾部）

File Header头部文件
作用：描述各种页的通用信息。（比如页的编号，其上一页，下一页是谁等）
大小：38字节
其中包含：

• FIL_PAGE_OFFSET(4字节) 页号
• FIL_PAGE_TYPE(2字节) 该页的类型
• FIL_PAGE_PREV(4字节)和FIL_PAGE_NEXT(4字节) 上一页的页号和下一页的页号
• FIL_PAGE_SPACE_OR_CHKSUM(4字节) 页的校验和checksum值
• FIL_PAGE_LSN(8字节) 页面被最后修改时对应的日志序列位置
• FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID(4字节)页属于哪个空间

FIL_PAGE_OFFSET(4字节)  页号

• 每一个页都有一个单独的页号，跟身份证号码一样，InnoDB通过页号可以唯一定位一个页。

FIL_PAGE_TYPE(2字节)  该页的类型

• FIL_PAGE_UNDO_LOG Undo日志页
• FIL_PAGE_TYPE_SYS 系统页
• FIL_PAGE_INDEX 索引页，也就是我们说的数据页

FIL_PAGE_PREV(4字节)和FIL_PAGE_NEXT(4字节)  上一页的页号和下一页的页号

• InnoDB都是以页为单位存放数据的，如果数据分散到多个不连续的页中存储的话需要把这些页关联起来，FIL_PAGE_PREV(4字节)和FIL_PAGE_NEXT(4字节)就代表本页的上一页和下一页，这样通过建立一个双线链表可以把许多的页串联起来，保证这些页不需要是物理上的连续，而是逻辑上的连续。 FIL_PAGE_SPACE_OR_CHKSUM(4字节) 页的校验和checksum值
• 代表当前页的校验和

什么是校验和？

• 就是对于一个很长的字符串来说，我们会通过某种算法来计算一个比较短的值来代表这个很长的字符串，这个比较短的值就叫做校验和。在比较两个很长的字符串之前，先比较这两个长字节串的校验和，如果校验的都不一样，则两个长字节串肯定不同，所以省去直接比较两个比较长的字符串的时间损耗。
• 文件头部和尾部都有的属性FIL_PAGE_SPACE_OR_CHKSUM

作用

• InnoDB存储引擎以页为单位把数据加载到内存中处理，如果该页的数据在内存中被修改，那么修改后的某个时间需要把数据同步到磁盘当中但是同步一半的时候，断电了造成了传输不完整。
• 为了检测一个页是否完整，这时可以通过文件尾部的校验和与文件头的校验和做对比，如果两个值不相等则证明传输有问题，需要重新传输，否则认为页的传输已经完成。

具体的

• 每当一个页面在内存中修改了，在同步之前就需要把他的校验和算出来，因为File Header在页面的前面，所以校验和会首先被同步到磁盘，当完全写完的时候，校验和也会被写道页的尾部，如果完全同步成功，则页的首部和尾部的校验和是一样的，如果写一半发生了意外，那么在File header中的校验和就代表已经修改过的页，而在File header中的校验和代表原先的页，二者不同意味着同步中间出现了问题，这里校验的方式就是采用Hash算法进行校验。

File Trailer尾部文件

• 前四个字节代表页的校验和：这个部分是和头部文件的校验和相对应
• 后四个字节代表页面被最后修改时对应的日志序列位置（LSN）。这个部分也是为了校验页的完整性，如果首部和尾部的LSN值校验不成功，就说明同步过程出现了问题。

第二部分：Free Space（空闲空间）、User Records（用户记录）和Infimum+Supremum（最大最小记录）

第二部分主要是记录部分，页的主要作用是存储记录，所以最大和最小记录和用户记录占用了页结构的主要空间。

新分配的页

• 文件头-确定
• 页头-确定
• 最大最小记录-确定
• 空闲空间
• （用户记录）
• 页目录-确定
• 文件尾-确定

Free Space（空闲空间）
我们自己存储的记录会按照行格式存储到User Records部分，但是在一开始生成页的时候，没有这个部分，当我们插入一条记录，都会从Free Space部分，也就是空闲空间中申请一个记录大小的空间划分到User Records部分，如果空闲空间被用户记录用完了 ，那也就意味着这个页用完了，需要重新申请新的页。

User Records（用户记录）
记录是按照指定的行格式一条一条摆在用户记录部分，互相之间形成单链表。
用户记录里的一条条数据如何记录

这里需要讲讲记录行格式的记录头信息

讲到记录头信息里面有：

• delete_mask 这个属性记录着当前记录是否被删除，占用1个二进制位
• min_rec_mask
• record_type
• heap_no
• n_owned
• next_record

delete_mask
这个属性记录着当前记录是否被删除，占用1个二进制位

• 值为0，代表没有被删除
• 值为1，代表被删除

那为什么被删除的记录还在页中存储呢？
你以为它删除了，其实它还在磁盘上，这些被删除的记录不是立即从磁盘上移除，是因为移除他们需要重新排列，导致性能消耗，所以只是打个删除标记而已，所有被删除的记录都会组成一个垃圾链表，在这个链表中记录占用的空间称为可重用空间之后如果有新的记录插入到表中的话，可能把这些被删除的记录占用的存储空间覆盖掉。

min_rec_mask
B+树的每层非叶子节点的最小记录都会添加该标记，min_rec_mask的值为1，我们自己插入的四条记录min_rec_mask值都是0，意味着他们都不是B+树的非叶子节点中的最小记录

record_type
一共有四种类型记录

• 0表示普通记录
• 1表示B+树的非叶节点记录
• 2表示最小记录
• 3表示最大记录

从中我们也可以看出来，我们自己插入的记录就是普通的记录，他们的值都是0，而最大最小记录的值分别为2和3，至于1的情况我们在索引数据结构章节有讲过。
heap_no
这个属性表示当前记录在本页的位置

为什么不见0和1呢
MySQL会自动给每个页加入了2个记录，由于两个记录不是我们插入的，所以称为伪记录或者虚拟记录，这两个伪记录一个代表最小记录，一个代表最大记录最小和最大记录分别是0和1，也就是说他们的位置最靠前。

Infimum+Supremum（最大最小记录）

记录可以比较大小吗？
是的记录可以比较大小，对于一条完整的记录，比较记录的大小就是比较主键的大小。
InnoDB规定的最小记录和最大记录这两条记录的构造十分简单，都是由5个字节大小的记录头信息和8字节大小的一个固定部分组成
这两条记录并不是我们自己定义的记录，所以他们并不存在页的User Records部分，他们被单独存放在一个叫Infimum+Supremum的部分。

n_owned
页目录中每个组中最后一条记录的头信息中会存储该组一共有多少条信息，作为n_owned字段
接着跳到 Page Directory

next_record
记录头信息这个属性非常重要，它表示从当前记录到下一条记录中的真实数据的地址偏移量
比如第一条数据的值为32，意味着从第一条记录的真是数据的地址向后找32个字节便是下一条记录的真是数据

注意：下一条记录指的并不是按照我们插入顺序的下一条记录，而是按照主键值由小到大的顺序下一条记录，而且规定Infimum记录（也就是最小记录）的下一条记录就是本页中主键值最小的用户记录，而本页中的主键值最大的用户记录的下一条记录就是Supremum记录（也就是最大记录）

next_record

• 删除操作，从表中删除一条操作，这个链表也会跟着变化：
• 1.首先是delete_mask的值会被设置成1
• 2.前面的记录也会跳过删除的记录，指向删除记录的后一条记录。
• 3.next_record也会变成0，意味着没有下一条记录了
• 4.最大记录中的n_owned会减1

所以，不论我们怎么对页中的记录做增删改查操作，InnoDB始终会一直维护一条记录的单链表，链表中的各个节点是按照主键值由小到大的顺序链接起来的。

• 添加操作，从表中添加一条操作，这个链表也会跟着变化：
• 直接复用原来被删除的记录的空间

说明：
当数据页中存在多条被删除掉的记录时，这些记录的next_record属性将会把这些被删除掉的记录组成一个垃圾链表，以备之后重用这部分存储空间。

第三部分：Page Directory（页目录）和Page Header（页面头部）

<strong>Page Directory（页目录）</strong>
为什么需要页面目录？
在页中，记录是以单链表的形式存储，单链表的特点就是插入，删除非常方便，但是检索效率不高，最差的情况下需要遍历链表上的所有节点才能完成检索，因此在页结构中专门设计了页目录这个模块，专门给记录做一个目录，通过二分查找法的方式进行检索，提高效率。

需求：根据主键值查找页中的某条记录，如何实现快速查找？
SELECT * FROM teble WHERE c1=3;
方式1：顺序查找
从最小记录中开始，沿着链表一直往后找，总有一次会找到，在找的时候可以投机取巧，以为链表各个记录是从小到大的顺序排序的，所以当链表的某个节点代表记录的主键值大于你想要查找的主键值时，你就可以停止查找，因为该节点后边的节点的主键依次递增。

如果一个页中存储了很多记录， 那么查找性能很差。

方式2：使用页目录，二分查找

• 1.将所有记录分成几个组，这些记录包括最小记录和最大记录，但不包括已被删除的记录。
• 2.第一组，也就是最小记录所在的分组只有一个记录；最后一组也就是最大记录所在的分组有1-8条记录
• 其余的组的记录数量在4—8条 这样做的好处是，除了第1组（最小记录所在组）以外，其余组的记录数会尽量平分。
• 3.在每个组中最后一条记录的头信息中会存储该组一共有多少条记录，作为n_owned字段
• 4.页目录用来存储每组最后一条记录的地址偏移量，这些地址偏移量会按照先后顺序存储起来，每组的地址偏移量也被称之为槽slot每个槽相当于指针指向了不同组的最后一个记录。

<strong>Page Header（页面头部）</strong>
为了能得到一个数据页中存储的记录状态信息，比如本页中已经存储了多少条记录，第一条记录的地址是什么，页目录中存储了多少个槽位等等，特意在页中定义了一个叫Page Header 的部分，这个部分占用固定的56个字节，专门存储各种状态信息。

PAGE_DIRECTION和PAGE_N_DIRECTION

PAGE_N_OIR_SLOTS—2字节—在页目录中槽的数量
PAGE_DIRECTION—2字节—记录插入的方向
PAGE_N_DIRECTION—2字节—一个方向连续插入的记录数量

从数据页角度看B + 树如何查询

一棵B+树按照节点类型可以分成两部分:
1．叶子节点，B+树最底层的节点，节点的高度为o，存储行记录。
2．非叶子节点，节点的高度大于0，存储索引键和页面指针，并不存储行记录本身。

当我们从页结构来理解B+树的结构的时候，可以帮我们理解一些通过索引进行检索的原理:

1.B+树是如何进行记录检索的?

如果通过B+树的索引查询行记录，首先是从B+树的根开始，逐层检索，直到找到叶子节点，也就是找到对应的数据页为止，将数据页加载到内存中，页目录中的槽(slot)采用二分查找的方式先找到一个粗略的记录分组然后再在分组中通过链表遍历的方式查找记录。

2.普通索引和唯一索引在查询效率上有什么不同?

我们创建索引的时候可以是普通索引，也可以是唯一索引，那么这两个索引在查询效率上有什么不同呢?

唯一索引就是在普通索引上增加了约束性，也就是关键字唯一，找到了关键字就停止检索。而普通索引，可能会存在用户记录中的关键字相同的情况，根据页结构的原理，当我们读取一条记录的时候，不是单独将这条记录从磁盘中读出去，而是将这个记录所在的页加载到内存中进行读取。InnoDB存储引擎的页大小为16KB，在一个页中可能存储着上千个记录，因此在普通索引的字段上进行查找也就是在内存中多几次“判断下一条记录”的操作，对于CPU来说，这些操作所消耗的时间是可以忽略不计的。所以对一个索引字段进行检索，采用普通索引还是唯一索引在检索效率上基本上没有差别。

三、InnoDB行格式(或记录格式)

我们平时的数据以行为单位来向表中插入数据，这些记录在磁盘上的存放方式也被称为行格式或者记录格式。InnoDB存储引擎设计了4种不同类型的行格式，分别是Compact（紧密）、Redundant（冗余）、Dynamic（动态）和Compressed（压缩）行格式。查看

MySQL8 的默认行格式:

(Wed Aug 10 10:30:58 2022)[root@GreatSQL][(none)]>select @@innodb_default_row_format;+-----------------------------+| @@innodb_default_row_format |+-----------------------------+| dynamic                     |+-----------------------------+1 row in set (0.00 sec)

指定行格式语法

在创建或修改表的语句中指定行格式
CREATE TABLE 表名（列的信息）ROW_FORMAT=行格式名称
ALTER TABLE 表名 ROW_FORMAT=行格式名称

举例：CREATE TABLE test(cool INT,cool2 CHAR(8))CHARSET=ascii ROW_FORMAT=COMPACT;

COMPACT行格式

在MySQL 5.1版本中，默认设置为Compact行格式，一条完整的记录其实可以被分为记录的额外信息和记录的真实数据两大部分
记录的额外信息分为：

• 变长字段长度列表 在COMPACT行格式中，把所有变长字段的真实数据占用的字节长度都存在在记录的开头部位，从而形成一个变长字段长度列表 注意：这里面存储的变长长度和字段顺序是反过来的
• NULL值列表 Compact行格式会把可以为NULL的列统一管理起来，存在一个标记为NULL值列表中。 为什么定义NULL值列表 之所以要存储NULL是因为数据需要对齐，如果没有标注出来NULL值的位置，就有可能在查询数据的时候出现混乱，如果使用一个特定的符号放到相应的数据位表示空置的话，虽然能达到效果，但是这样很浪费空间所以直接在行数据头部开辟一块空间，专门用来记录该行数据那些是非空数据，哪些是空数据。 二进制位值为1，代表该列的值为NULL二进制位值为2，代表该列的值不为NULL
• 记录头信息 delete_maskmin_rec_maskrecord_typeheap_non_ownednext_record
• 记录真实数据 记录真实数据除了我们自己定义的列的数据以外，还有三个隐藏列

一个表如果没有手动定义主键，则会选取一个Unique键作为主键，如果没有Unique键，则会为表默认添加一个row_id的隐藏列作为主键
在.ibd二进制文件内容如下：
（‘a’,‘bb’,‘bb’,‘ccc’）

0000c070 73 75 70 72 65 6d -03 02 01- -00- -00 00 10 00- |supremun..........|0000c080 -2c- -00 00 00 2b 68 00- -00 00 00 00 06 05- -80 00 00 |，...+h..........|0000c090 00 32 01 10- -61- -62 62- -62 62 20 20 20 20 20 20 20 |.2..abbbb|0000c0a0 20- -63 63 63- -下一段数据-

其中第一段03 02 01是变长字段长度列表，是逆序的

第二段00 是NULL标志位，第一行没有NULL值

第三段00 00 10 00 2c 是Record Header (记录头信息)固定5字节长度，其中00 2c是下一条的偏移量

第四段00 00 00 2b 68 00  是row_id

第五段00 00 00 00 06 05是transaction_id 事务ID

第六段80 00 00 00 32 01 10是roll_pointer 回滚指针

第七段61对应的是里面放的a值

第八段62 62是bb

第九段62 62 20 20 20 20 20 20 20这么长是因为定长的bb

第十段63 63 63是ccc

注意（‘d’,NULL,NULL,‘fff’）
第二段06 是NULL标志位
为什么是06 是因为 NULL标记为1，即为 0110 所以为6

Dynamic和Compressed行格式

和Compact差别不大

行溢出
InnoDB存储引擎可以将一条记录中的某些数据存储在真正的数据页面之外。
很多DBA喜欢MySQL数据库提供的VARCHAR(M)类型，认为可以存放65535个字节，这是真的吗，如果我们用ascii字符集的话，一个字符就代表一个字节，我们看看VARCHAR(65535)是否可用

结果是不可用的，实际上是达不到65535的 需要减去3个才可以创建成功65533+2字节变长字段的长度+Null值的标识

通过上面的例子可以看出来，我们一页的大小是16KB也就是16384字节，而一个VARCHAR(M)类型最多可以存储65533个字节，这样就可能出现一个页存放不了一条记录，这种现象称为行溢出
在Compac和Reduntant行格式中，对于占用存储空间特别大的列，在记录真实数据处只会存储该列的一部分数据，把剩余的数据分散存储在几个其他的页进行分页存储然后记录的真实数据处用20个字节存储指向这些页的地址（当然这20个字节中还包括这些分散在其他页面的数据的占用的字节数），从而可以找到剩余数据所在的页。这称为页的扩展

Dynamic和Compressed行格式
在MySQL8.0中，默认行格式是Dynamic、Dynamic和Compressed行格式和Compact行格式挺像，只不过在处理行溢出的时候有分歧：

• Dynamic和Compressed行格式对于存放在BLOB中的数据采用了完全的行溢出方式，在数据页中只存放20个字节的指针（溢出页的地址），实际的数据都存放在Off Page（溢出页）中。
• COMPACT和Redundant两种格式会在记录的真实数据处存储一部分数据（存放768个前缀字节）

Compressed
另一个功能就是存储在其中行数据会以zlib的算法进行压缩，因此BLOB\TEXT\VARCHAR这类大长度类型的数据能够进行非常有效的存储。
Redundant
是MySQL5.0之前InnoDB的行记录存储方式，只是为了兼容之前版本。
COMPACT行格式开头是变长字段长度列表，而Redundant开头是字段长度偏移列表

• 少了变长两个字，Redundant行格式会把该条记录中所有列（包括隐藏列）的长度信息都按照逆序存储到字段长度偏移列表中
• 多了偏移两字，意味着计算列值长度的方式不像COMPACT行格式那么直观，他是采用两个相邻数值的差值来计算各个列值的长度。

四、区、段与碎片区

为什么要有区?

B+树的每一层中的页都会形成一个双向链表，如果是以页为单位来分配存储空间的话，双向链表相邻的两个页之间的物理位置可能离得非常远。我们介绍B+树索引的适用场景的时候特别提到范围查询只需要定位到最左边的记录和最右边的记录,然后沿着双向链表一直扫描就可以了，而如果链表中相邻的两个页物理位置离得非常远，就是所谓的随机I/O。再一次强调，磁盘的速度和内存的速度差了好几个数量级，随机I/O是非常慢的，所以我们应该尽量让链表中相邻的页的物理位置也相邻，这样进行范围查询的时候才可以使用所谓的顺序I/O。

引入区的概念，一个区就是在物理位置上连续的64个页。因为InnoDB 中的页大小默认是16KB，所以一个区的大小是64*16KB=1MB。在表中数据量大的时候，为某个索引分配空间的时候就不再按照页为单位分配了，而是按照区为单位分配，甚至在表中的数据特别多的时候，可以一次性分配多个连续的区。虽然可能造成一点点空间的浪费（数据不足以填充满整个区)，但是从性能角度看，可以消除很多的随机I/O

为什么要有段?

对于范围查询，其实是对B+树叶子节点中的记录进行顺序扫描，而如果不区分叶子节点和非叶子节点，统统把节点代表的页面放到申请到的区中的话，进行范围扫描的效果就大打折扣了。所以InnoDB对B+树的叶子节点和非叶子节点进行了区别对待，也就是说叶子节点有自己独有的区，非叶子节点也有自己独有的区。存放叶子节点的区的集合就算是一个段( segment)，存放非叶子节点的区的集合也算是一个段。也就是说一个索引会生成2个段，一个叶子节点段，一个非叶子节点段。

除了索引的叶子节点段和非叶子节点段之外，InnoDB中还有为存储一些特殊的数据而定义的段，比如回滚段。所以，常见的段有数据段、索引段、回滚段。数据段即为B+树的叶子节点，索引段即为B+树的非叶子节点。

在InnoDB存储引擎中，对段的管理都是由引擎自身所完成，DBA不能也没有必要对其进行控制。这从一定程度上简化了DBA对于段的管理。

段其实不对应表空间中某一个连续的物理区域，而是一个逻辑上的概念，由若干个零散的页面以及一些完整的区组成。

为什么要有碎片区?

默认情况下，一个使用InnoDB存储引擎的表只有一个聚簇索引，一个索引会生成2个段，而段是以区为单位申请存储空间的，一个区默认占用1M (64*16Kb=1024Kb）存储空间，所以默认情况下一个只存了几条记录的小表也需要2M的存储空间么?以后每次添加一个索引都要多申请2M的存储空间么?这对于存储记录比较少的表简直是天大的浪费。这个问题的症结在于到现在为止我们介绍的区都是非常纯粹的，也就是一个区被整个分配给某一个段，或者说区中的所有页面都是为了存储同一个段的数据而存在的，即使段的数据填不满区中所有的页面，那余下的页面也不能挪作他用。

为了考虑以完整的区为单位分配给某个段对于数据量较小的表太浪费存储空间的这种情况，InnoDB提出了一个碎片(fragment)区的概念。在一个碎片区中，并不是所有的页都是为了存储同一个段的数据而存在的，而是碎片区中的页可以用于不同的目的，比如有些页用于段A，有些页用于段B，有些页甚至哪个段都不属于。碎片区直属于表空间，并不属于任何一个段。

所以此后为某个段分配存储空间的策略是这样的:

• 在刚开始向表中插入数据的时候，段是从某个碎片区以单个页面为单位来分配存储空间的
• 当某个段已经占用了32个碎片区页面之后，就会申请以完整的区为单位来分配存储空间。

所以现在段不能仅定义为是某些区的集合，更精确的应该是某些零散的页面以及一些完整的区的集合。

区的分类

区大体上可以分为4种类型:

• 空闲的区(FREE): 现在还没有用到这个区中的任何页面。
• 有剩余空间的碎片区(FREE_FRAG): 表示碎片区中还有可用的页面。
• 没有剩余空间的碎片区(FULL_FRAG)︰表示碎片区中的所有页面都被使用，没有空闲页面。
• 附属于某个段的区(FSEG):每一个索引都可以分为叶子节点段和非叶子节点段。

处于FREE、FREE_FRAG以及FULL_FRAG这三种状态的区都是独立的，直属于表空间。而处于FSEG状态的区是附属于某个段的。

五、表空间

表空间可以看做是InnoDB存储引擎逻辑结构的最高层，所有的数据都存放在表空间中。

表空间是一个逻辑容器，表空间存储的对象是段，在一个表空间中可以有一个或多个段，但是一个段只能属于一个表空间。表空间数据库由一个或多个表空间组成，表空间从管理上可以划分为系统表空间 (Systemtablespace)、独立表空间(File-per-table tablespace)、撤销表空间(Undo Tablespace)和临时表空间(Temporary Tablespace）等。

独立表空间

独立表空间，即每张表有一个独立的表空间，也就是数据和索引信息都会保存在自己的表空间中。独立的表空间(即:单表)可以在不同的数据库之间进行迁移。

空间可以回收(DROPTABLE操作可自动回收表空间;其他情况，表空间不能自己回收)。如果对于统计分析或是日志表，删除大量数据后可以通过: alter table TableName engine=innodb;回收不用的空间。对于使用独立表空间的表，不管怎么删除，表空间的碎片不会太严重的影响性能，而且还有机会处理。

独立表空间结构

独立表空间由段、区、页组成。

真实表空间对应的文件大小
我们到数据目录里看，会发现一个新建的表对应的.ibd文件只占用了96K，才6个页面大小(MySQL5.7中)，这是因为一开始表空间占用的空间很小，因为表里边都没有数据。不过别忘了这些.ibd文件是自扩展的，随着表中数据的增多，表空间对应的文件也逐渐增大。

查看InnoDB的表空间类型:

(Wed Aug 10 15:41:37 2022)[root@GreatSQL][(none)]>show variables like 'innodb_file_per_table';+-----------------------+-------+| Variable_name         | Value |+-----------------------+-------+| innodb_file_per_table | ON    |+-----------------------+-------+1 row in set (0.00 sec)

MySQL8.0中 7个页面大小。原因.idb 还存了 表结构表结构.frm取消了

系统表空间

系统表空间的结构和独立表空间基本类似，只不过由于整个MySQL进程只有一个系统表空间，在系统表空间中会额外记录一些有关整个系统信息的页面，这部分是独立表空间中没有的。

lnnoDB数据字典

每当我们向一个表中插入一条记录的时候，MySQL校验过程如下:

先要校验一下插入语句对应的表存不存在，插入的列和表中的列是否符合，如果语法没有问题的话，还需要知道该表的聚簇索引和所有二级索引对应的根页面是哪个表空间的哪个页面，然后把记录插入对应索引的B+树中。所以说，MySQL除了保存着我们插入的用户数据之外，还需要保存许多额外的信息，比方说:

-某个表属于哪个表空间，表里边有多少列-表对应的每一个列的类型是什么-该表有多少索引，每个索引对应哪几个字段，该索引对应的根页面在哪个表空间的哪个页面-该表有哪些外键，外键对应哪个表的哪些列-某个表空间对应文件系统上文件路径是什么

上述这些数据并不是我们使用INSERT语句插入的用户数据，实际上是为了更好的管理我们这些用户数据而不得已引入的一些额外数据，这些数据也称为元数据。InnoDB存储引擎特意定义了一些列的内部系统表(internalsystem table)来记录这些这些元数据:

这些系统表也被称为数据字典，它们都是以B+树的形式保存在系统表空间的某些页面中，其中SYS_TABLES.
SYS_COLUNNS、SYS_INDEXES、SYS_FIELDS这四个表尤其重要，称之为基本系统表(basic system tables)

SYS_TABLES表结构

SYS_COLUMNS表结构表结构

SYS_INDEXES表结构

SYS_FIELDS表结构

注意:用户是不能直接访问InnoDB的这些内部系统表，除非你直接去解析系统表空间对应文件系统上的文件。不过考虑到查看这些表的内容可能有助于大家分析问题，所以在系统数据库information_schema中提供了一些以innodb_sys开头的表:
在MySQL8.0中已经改名为innodb_XXX，不在是innodb_sys开头。

(Wed Aug 10 16:25:12 2022)[root@GreatSQL][information_schema]>USE information_schema ;Database changed(Wed Aug 10 16:25:16 2022)[root@GreatSQL][information_schema]>SHOW TABLES LIKE 'innodb_%';+-----------------------------------------+| Tables_in_information_schema (INNODB_%) |+-----------------------------------------+| INNODB_BUFFER_PAGE                      || INNODB_BUFFER_PAGE_LRU                  || INNODB_BUFFER_POOL_STATS                || INNODB_CACHED_INDEXES                   || INNODB_CHANGED_PAGES                    || INNODB_CMP                              || INNODB_CMPMEM                           || INNODB_CMPMEM_RESET                     || INNODB_CMP_PER_INDEX                    || INNODB_CMP_PER_INDEX_RESET              || INNODB_CMP_RESET                        || INNODB_COLUMNS                          || INNODB_DATAFILES                        || INNODB_FIELDS                           || INNODB_FOREIGN                          || INNODB_FOREIGN_COLS                     || INNODB_FT_BEING_DELETED                 || INNODB_FT_CONFIG                        || INNODB_FT_DEFAULT_STOPWORD              || INNODB_FT_DELETED                       || INNODB_FT_INDEX_CACHE                   || INNODB_FT_INDEX_TABLE                   || INNODB_INDEXES                          || INNODB_METRICS                          || INNODB_SESSION_TEMP_TABLESPACES         || INNODB_TABLES                           || INNODB_TABLESPACES                      || INNODB_TABLESPACES_BRIEF                || INNODB_TABLESPACES_ENCRYPTION           || INNODB_TABLESPACES_SCRUBBING            || INNODB_TABLESTATS                       || INNODB_TEMP_TABLE_INFO                  || INNODB_TRX                              || INNODB_VIRTUAL                          |+-----------------------------------------+34 rows in set (0.01 sec)

在information_schema数据库中的这些以INNODB_SYS开头的表并不是真正的内部系统表(内部系统表就是我们上边以SYS开头的那些表)，而是在存储引擎启动时读取这些以SYS开头的系统表，然后填充到这些以
INNODB_SYS开头的表中。以INNODB_SYS开头的表和以SYS开头的表中的字段并不完全一样，但供大家参考已经足矣。