大家都知道 MySQL 的数据都是保存在磁盘的，那具体是保存在哪个文件呢？MySQL 存储的行为是由存储引擎实现的，MySQL 支持多种存储引擎，不同的存储引擎保存的文件自然也不同。InnoDB 是我们常用的存储引擎，也是 MySQL 默认的存储引擎。本文主要以 InnoDB 存储引擎展开讨论。

InnoDB是一个将表中的数据存储到磁盘上的存储引擎。而真正处理数据的过程是发生在内存中的，所以需要把磁盘中的数据加载到内存中，如果是处理写入或修改请求的话，还需要把内存中的内容刷新到磁盘上。而我们知道读写磁盘的速度非常慢，和内存读写差了几个数量级。所以当我们想从表中获取某些记录时，InnoDB存储引擎需要一条一条的把记录从磁盘上读出来么？想要了解这个问题，我们首先需要了解InnoDB的存储结构是怎样的。

InnoDB采取的方式是：将数据划分为若干个页，以页作为磁盘和内存之间交互的基本单位innodb_page_size选项指定了MySQL实例的所有InnoDB表空间的页面大小。这个值是在创建实例时设置的，之后保持不变。有效值为64KB，32KB，16KB(默认值 )，8kB和4kB。也就是在一般情况下，一次最少从磁盘中读取16KB的内容到内存中，一次最少把内存中的16KB内容刷新到磁盘中。

我们平时是以记录为单位来向表中插入数据的，这些记录在磁盘上的存放方式也被称为行格式或者记录格式。一行记录可以以不同的格式存在InnoDB中，行格式分别是compact、redundant、dynamic和compressed行格式。可以在创建或修改的语句中指定行格式：

mysql5.0之前默认的行格式是redundant，mysql5.0之后的默认行格式为compact ， 5.7之后的默认行格式为dynamic

记录的额外信息

记录的额外信息：分别是变长字段长度列表、NULL值列表和记录头信息

1：变长字段长度列表

mysql中支持一些变长数据类型（比如VARCHAR(M)、TEXT等），它们存储数据占用的存储空间不是固定的，而是会随着存储内容的变化而变化。在Compact行格式中，把所有变长字段的真实数据占用的字节长度都存放在记录的开头部位，从而形成一个变长字段长度列表，各变长字段数据占用的字节数按照列的顺序逆序存放

2：NULL值列表

NULL值列表：Compact格式会把所有可以为NULL的列统一管理起来，存在一个NULL值列表，如果表中没有允许为NULL的列，则NULL值列表也不复存在了。

为什么要有NULL值列表？

表中的某些列可能存储NULL值，如果把这些NULL值都放到记录的真实数据中存储会很浪费空间，所以Compact行格式把这些值为NULL的列统一管理起来，存储到NULL值列表中，它的处理过程是这样的：

3：记录头信息

与compact 格式相比, 没有了 变长字段列表以及 NULL值列表, 取而代之的是 记录了所有真实数据的偏移地址表 ，偏移地址表 是倒序排放的, 但是计算偏移量却还是正序开始的从row_id作为第一个, 第一个从0开始累加字段对应的字节数。在记录头信息中, 大部分字段和compact 中的相同，但是对比compact多了。

n_field(记录列的数量)、1byte_offs_flag(字段长度列表每一列占用的字节数)，少了record_type字段。

因为redundant是mysql 5.0 以前就在使用的一种格式, 已经非常古老, 使用频率非常的低，这里就不过多表述。

在现在 mysql 5.7 的版本中,使用的格式就是 dynamic。

dynamic 和 compact 基本是相同的，只有在溢出页的处理上面,有所不同。

在compact行格式中，对于占用存储空间非常大的列，在记录的真实数据处只会存储该列的前768个字节的数据，把剩余的数据分散存储在几个其他的页中，然后记录的真实数据处用20个字节存储指向这些页的地址，从而可以找到剩余数据所在的页。

这种在本记录的真实数据处只会存储该列的前768个字节的数据和一个指向其他页的地址，然后把剩下的数据存放到其他页中的情况就叫做行溢出，存储超出768字节的那些页面也被称为溢出页（uncompresse blob page）。

dynamic中会直接在真实数据区记录 20字节 的溢出页地址, 而不再去额外记录一部分的数据了。

行溢出临界点

MySQL中规定一个页中至少存放两行记录。简单理解：因为B+树的特性，如果不存储至少2条记录，则这个B+树是没有意义的，形不成一个有效的索引。

每个页除了存放我们的记录以外，也需要存储一些额外的信息，大概132个字节。

每个记录需要的额外信息是27字节。假设一个列中存储的数据字节数为n，如要要保证该列不发生溢出，则需要满足：132 + 2×(27 + n) < 16384 结果是n < 8099。也就是说如果一个列中存储的数据小于8099个字节，那么该列就不会成为溢出列。如果表中有多个列，那么这个值更小。

compressed 格式将会在Dynamic 的基础上面进行压缩处理特别是对溢出页的压缩处理，存储在其中的行数据会以zlib的算法进行压缩，因此对于blob、text这类大长度类型的数据能够进行非常有效的存储。但compressed格式其实也是以时间换空间，性能并不友好，并不推荐在常见的业务中使用。

数据页代表的这块16KB大小的存储空间可以被划分为多个部分，不同部分有不同的功能

每当我们插入一条记录，都会从Free Space部分，也就是尚未使用的存储空间中申请一个记录大小的空间划分到User Records部分，当Free Space部分的空间全部被User Records部分替代掉之后，也就意味着这个页使用完了，如果还有新的记录插入的话，就需要去申请新的页了，这个过程的图示如下：

为了方便讲述

这些记录，就如下图所示，存储在User Rcords里

从图中可以看出来，我们的记录按照主键从小到大的顺序形成了一个单链表。

现在我们了解了记录在页中按照主键值由小到大顺序串联成一个单链表，单向链表的特点就是插入、删除非常方便，但是检索效率不高，最差的情况下需要遍历链表上的所有节点才能完成检索。因此在页结构中专门设计了页目录这个模块，专门给记录做一个目录，通过二分查找法的方式进行检索，提升效率。

1：将所有正常的记录（包括最大和最小记录，不包括标记为已删除的记录）划分为几个组。

2：每个组的最后一条记录（也就是组内最大的那条记录）的头信息中的n_owned属性表示该记录拥有多少条记录，也就是该组内共有几条记录。

3：将每个组的最后一条记录的地址偏移量单独提取出来，用作查找。

注意：这个页目录是为主键服务的。

需要注意的是：

第一：第一个小组，也就是最小记录所在的分组只能有1个记录;

第二：最后一个小组，就是最大记录所在的分组，只能有1-8条记录;

第三：剩下的分组中记录的条数范围只能在是 4-8 条之间；

分组是按照下边的步骤进行：

1.通过二分法确定该记录所在的槽，并找到该槽所在分组中主键值最大的那条记录。

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

FIL_PAGE_PREV和FIL_PAGE_NEXTFIL_PAGE_PREV和FIL_PAGE_NEXT就分别代表本页的上一个和下一个页的页号。这样通过建立一个双向链表把许许多多的页就都串联起来了。

InnoDB数据页的主要组成部分。各个数据页可以组成一个双向链表，而每个数据页中的记录会按照主键值从小到大的顺序组成一个单向链表，每个数据页都会为存储在它里边儿的记录生成一个页目录。再通过主键查找某条记录的时候可以在页目录中使用二分法快速定位到对应的槽。

在一个页中的查找：

在很多页中查找：

2：从所在的页内中查找相应的记录。

在没有索引的情况下，不论是根据主键列或者其他列的值进行查找，由于我们并不能快速的定位到记录所在的页，所以只能从第一个页沿着双向链表一直往下找，在每一个页中根据我们上面聊过的查找方式去查找指定的记录。

同样的，我们以上面建的表test为例，清空插入的数据，此时test表为一张空数据的表，为了便于讲述，我们可以简单的把test表的行格式理解如下：

一个简单的索引方案：我们为根据主键值快速定位一条记录在页中的位置而设立的页目录，目录中记录的数据页需要满足下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值。

假设我们的每个数据页最多能存放3条记录（实际上一个数据页非常大，可以存放下很多记录），这时候我们向test表插入三条记录，那么数据页就如图所示：

此时我们再来插入一条记录：

因为上面定义了，一个页最多只能放3条记录，所以我们不得不再分配一个新页：

页1中用户记录最大的主键值是4，而页2中有一条记录的主键值是3，因为4 > 3，所以这就不符合下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值的要求，所以在插入主键值为3的记录的时候需要伴随着一次记录移动，也就是把主键值为4的记录移动到页2中，然后再把主键值为3的记录插入到页1中。最后形成如图所示。

这个过程叫做页分裂。

真实数据存储中，数据页的编号并不是连续的，当我们在test表中插入多条记录后，可能是这样的效果：

因为这些16KB的页在物理存储上可能并不挨着，所以如果想从这么多页中根据主键值快速定位某些记录所在的页，我们需要给它们做个目录，每个页对应一个目录项，每个目录项由页中记录的最小主键值和页号组成。我们为上面几个页做目录，则如图：

比方说我们想找主键值为5的记录，具体查找过程分两步：

2：再根据前边说的在页中查找记录的方式去页23中定位具体的记录。

这个目录有一个别名，称为索引。

在InnoDB中复用了之前存储用户记录的数据页来存储目录项，为了和用户记录做一下区分，我们把这些用来表示目录项的记录称为目录项记录。

用record_type来区分普通的用户记录还是目录项记录。

如果表中的数据太多，以至于一个数据页不足以存放所有的目录项记录，会再多整一个存储目录项记录的页。所以如果此时我们再向上图中插入一条主键值为10的用户记录的话：

在查询时我们需要定位存储目录项记录的页，但是这些页在存储空间中也可能不挨着，如果我们表中的数据非常多则会产生很多存储目录项记录的页，那我们怎么根据主键值快速定位一个存储目录项记录的页呢？其实也简单，为这些存储目录项记录的页再生成一个更高级的目录，就像是一个多级目录一样，大目录里嵌套小目录，小目录里才是实际的数据，所以现在各个页的示意图就是这样子：

用户记录其实都存放在B+树的最底层的节点上，这些节点也被称为叶子节点或叶节点，其余用来存放目录项的节点称为非叶子节点或者内节点，其中B+树最上边的那个节点也称为根节点。

我们上边介绍的B+树本身就是一个目录，或者说本身就是一个索引。它有两个特点：

2：B+树的叶子节点存储的是完整的用户记录。

我们把具有这两种特性的B+树称为聚簇索引，所有完整的用户记录都存放在这个聚簇索引的叶子节点处。这种聚簇索引并不需要我们在MySQL语句中显式的使用INDEX语句去创建，InnoDB存储引擎会自动的为我们创建聚簇索引。另外有趣的一点是，在InnoDB存储引擎中，聚簇索引就是数据的存储方式（所有的用户记录都存储在了叶子节点），也就是所谓的索引即数据，数据即索引。

这个B+树与上边介绍的聚簇索引有几处不同：