9.2.1 区（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 这些区的属性。
9.2.2 段（segment）的概念
我们每向表中插入一条记录，本质上就是向该表的聚簇索引以及所有二级索引代表的 B+ 树的节点中插入数据。而 B+ 树的每一层中的页都会形成一个双向链表，如果是以 页 为单位来分配存储空间的话，双向链表相邻的两个页之间的物理位置可能离得非常远。我们介绍 B+ 树索引的适用场景的时候特别提到范围查询只需要定位到最左边的记录和最右边的记录，然后沿着双向链表一直扫描就可以了，而如果链表中相邻的两个页物理位置离得非常远，就是所谓的 随机I/O 。再一次强调，磁盘的速度和内存的速度差了好几个数量级， 随机I/O 是非常慢的，所以我们应该尽量让链表中相邻的页的物理位置也相邻，这样进行范围查询的时候才可以使用所谓的 顺序I/O 。
所以才引入了区的概念，一个区就是在物理位置上连续的64个页。在表中数据量大的时候，为某个索引分配空间的时候就不再按照页为单位分配了，而是按照 区 为单位分配，甚至在表中的数据十分非常特别多的时候，可以一次性分配多个连续的区。虽然可能造成一点点空间的浪费（数据不足填充满整个区），但是从性能角度看，可以消除很多的随机 I/O 。
范围查询实际是对B+树叶子节点中的记录进行顺序扫描，而如果不区分叶子节点和非叶子节点，把节点代表的页面放到申请到的区中的话，进行范围扫描效果就会下降。所以叶子节点有自己独有的区，非叶子节点也有自己独有的区。存放叶子节点的区的集合就算是一个段，存放非叶子节点的区的集合也算是一个段，一个索引会生成2个段，一个叶子节点段，一个非叶子节点段。
默认情况下一个使用 InnoDB 存储引擎的表只有一个聚簇索引，一个索引会生成2个段，而段是以区为单位申请存储空间的，一个区默认占用1M存储空间。默认情况下只存几条记录也会占存储空间，考虑到这个问题就引出了碎片区的概念，在一个碎片区中，并不是所有的页都是为了存储同一个段的数据而存在的，而是碎片区中的页可以用于不同的目的，比如有些页用于段A，有些页用于段B，有些页甚至哪个段都不属于。碎片区直属于表空间，并不属于任何一个段。所以此后为某个段分配存储空间的策略是这样的：
在刚开始向表中插入数据的时候，段是从某个碎片区以单个页面为单位来分配存储空间的。
当某个段已经占用了32个碎片区页面之后，就会以完整的区为单位来分配存储空间。
所以现在段不能仅定义为是某些区的集合，更精确的应该是某些零散的页面以及一些完整的区的集合。除了索引的叶子节点段和非叶子节点段之外， InnoDB 中还有为存储一些特殊的数据而定义的段，比如回滚段。
9.2.3 区的分类
表空间大体由若干个区组成的，这些区大体可以分为4种类型：
空闲的区：现在还没有用到这个区中的任何页面。
有剩余空间的碎片区：表示碎片区中还有可用的页面。
没有剩余空间的碎片区：表示碎片区中的所有页面都被使用，没有空闲页面。
附属于某个段的区。每一个索引都可以分为叶子节点段和非叶子节点段，除此之外InnoDB还会另外定义一些特殊作用的段，在这些段中的数据量很大时将使用区来作为基本的分配单位。
这4种类型的区也可以被称为区的4种状态：
状态名 |
含义 |
FREE |
空闲的区 |
FREE_FRAG |
有剩余空间的碎片区 |
FULL_FRAG |
没有剩余空间的碎片区 |
FSEG |
附属于某个段的区 |
处于 FREE 、 FREE_FRAG 以及 FULL_FRAG 这三种状态的区都是独立的，算是直属于表空间；而处于 FSEG 状态的区是附属于某个段的。
为了方便管理这些区，每个区都对应着一个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 的指针
State （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个页面。这两个比特位的第一个位表示对应的页是否是空闲的，第二个比特位还没有用。
