InnoDB一个支持事务安全的存储引擎，同时也是mysql的默认存储引擎。本文主要从数据结构的角度，详细介绍InnoDB行记录格式和数据页的实现原理，从底层看清InnoDB存储引擎。
InnoDB简介
大家都知道mysql中数据是存储在物理磁盘上的，而真正的数据处理又是在内存中执行的。由于磁盘的读写速度非常慢，如果每次操作都对磁盘进行频繁读写的话，那么性能一定非常差。为了上述问题，InnoDB将数据划分为若干页，以页作为磁盘与内存交互的基本单位，一般页的大小为16KB。这样的话，一次性至少读取1页数据到内存中或者将1页数据写入磁盘。通过减少内存与磁盘的交互次数，从而提升性能。
其实，这本质上就是一种典型的缓存设计思想，一般缓存的设计基本都是从时间维度或者空间维度进行考量的：
时间维度：如果一条数据正在在被使用，那么在接下来一段时间内大概率还会再被使用。可以认为热点数据缓存都属于这种思路的实现。空间维度：如果一条数据正在在被使用，那么存储在它附近的数据大概率也会很快被使用。InnoDB的数据页和操作系统的页缓存则是这种思路的体现。
InnoDB行格式
mysql是以记录(一行数据)为单位向数据表中插入数据的，这些记录在磁盘上的存放方式称为行格式。mysql支持4种不同类型的行格式：Compact、Redundant(比较老，本文就不具体介绍了)、Dynamic、Compressed。
我们可以在创建或修改表的语句中指定行格式：
比如，我们要创建一个行格式为Compact，字符集为ascii的数据表record_format_demo，sql如下：
假设我们向record_format_demo表中插入了2行数据：
COMPACT行格式
从上图可以看出，一条完整的记录包含记录的额外信息和记录的真实数据两大部分。
记录的额外信息
记录的额外信息主要包含3类：
变长字段长度列表、NULL值列表和记录头信息。
变长字段长度列表
mysql中支持一些变长数据类型(比如VARCHAR(M)、TEXT等)，它们存储数据占用的存储空间不是固定的，而是会随着存储内容的变化而变化。为了准确描述这种数据，这种变长字段占用的存储空间要同时包含：
真正的数据内容占用的字节数在Compact行格式中，把所有变长字段的真实数据占用的字节长度都存放在记录的开头部位，从而形成一个变长字段长度列表，各变长字段数据占用的字节数按照列的顺序逆序存放。
我们以record_format_demo第一行数据为例。由于c1、c2和c4都是变成数据类型(VARCHAR(10)),因此要将这3列值得长度保存在记录的开头处。
另外需要注意的一点是，变长字段长度列表中只存储值为 非NULL 的列内容占用的长度，值为 NULL 的列的长度是不储存的。也就是说对于第二条记录来说，因为c4列的值为NULL，所以第二条记录的变长字段长度列表只需要存储c1和c2列的长度即可。
NULL值列表
对于可为NULL的列，为了节约存储空间，mysql不会将NULL值保存在记录的真实数据部分。而是会将其保存在记录的额外信息里面的NULL值列表中。
具体的做法是先统计表中允许存储NULL值的列，然后将每个允许存储NULL值的列对应一个二进制位(1：值为NULL，0：值不为NULL)用来表示是否存储NULL值，并按照逆序排列。MySQL规定NULL值列表必须用整数个字节的位表示，如果使用的二进制位个数不是整数个字节，则在字节的高位补0。
对应record_format_demo表中，c1、c3、c4都是允许存储NULL值的。前两条记录在填充了NULL值列表后的示意图就是这样：
记录头信息
记录头信息是由固定的5个字节(40位)组成,不同的位代表不同的含义：
暂时不详细展开。
记录的真实数据
记录的真实数据除了包含各列具体的数据外，还会自动添加一些隐藏列数据。
实际上这几个列的真正名称其实是：DB_ROW_ID、DB_TRX_ID、DB_ROLL_PTR，为了美观才写成了row_id、transaction_id和roll_pointer。
只有当数据库没有定义主键或者唯一键时，隐藏列row_id才会存在，并且将其作为数据表主键。
因为表record_format_demo并没有定义主键，所以MySQL服务器会为每条记录增加上述的3个列。现在看一下加上记录的真实数据的两个记录的数据结构：
CHAR(M)列的存储格式
对于 CHAR(M) 类型的列来说，当列采用的是定长字符集时，该列占用的字节数不会被加到变长字段长度列表，而如果采用变长字符集时，该列占用的字节数也会被加到变长字段长度列表。另外有一点还需要注意，变长字符集的CHAR(M)类型的列要求至少占用M个字节，而VARCHAR(M)却没有这个要求。比方说对于使用utf8字符集的CHAR(10)的列来说，该列存储的数据字节长度的范围是10～30个字节，即使我们向该列中存储一个空字符串也会占用10个字节。
行溢出数据
VARCHAR(M)最多能存储的数据
MySQL对一条记录占用的最大存储空间是有限制的，除了BLOB或者TEXT类型的列之外，其他所有的列(不包括隐藏列和记录头信息)占用的字节长度加起来不能超过65535个字节。可以不严谨的认为，mysql一行记录占用的存储空间不能超过65535个字节。这个65535个字节除了列本身的数据之外，还包括一些其他的数据(storage overhead)，比如说我们为了存储一个VARCHAR(M)类型的列，其实需要占用3部分存储空间：
真实数据真实数据占用字节的长度NULL值标识，如果该列有NOT NULL属性则可以没有这部分存储空间假设varchar_size_demo只有一个VARCHAR类型的字段，那么该字段最大占用的65532个字节。因为真实数据的长度可能占用2个字节，NULL值标识需要占用1个字节。如果该VARCHAR类型的列没有NOT NULL属性，那最多只能存储65532个字节的数据。如果该列是ascii字符集，对应的最大字符数最大为65532；如果是utf8字符集，则对应的最大字符数为21844。
记录中的数据太多产生的溢出
我们以ascii字符集下的varchar_size_demo表为例，插入一条记录：
mysql中磁盘与内存交互的基本单位是页，一般为16KB，16384个字节，而一行记录最大可以占用65535个字节，这就造成了一页存不下一行数据的情况。在Compact和Redundant行格式中，对于占用存储空间非常大的列，在记录的真实数据处只会存储该列的一部分数据，把剩余的数据分散存储在几个其他的页中，然后记录的真实数据处用20个字节存储指向这些页的地址，从而可以找到剩余数据所在的页，如图所示：
这种在本记录的真实数据处只会存储该列的前768个字节的数据和一个指向其他页的地址，然后把剩下的数据存放到其他页中的情况就叫做行溢出，存储超出768字节的那些页面也被称为溢出页。
行溢出的临界点
MySQL中规定一个页中至少存放两行记录。以上边的varchar_size_demo表为例，它只有一个列c，我们往这个表中插入两条记录，每条记录最少插入多少字节的数据才会行溢出的现象呢？这得分析一下页中的空间都是如何利用的。
每个页除了存放我们的记录以外，也需要存储一些额外的信息，大概132个字节。每个记录需要的额外信息是27字节。假设一个列中存储的数据字节数为n，如要要保证该列不发生溢出，则需要满足：
132 + 2×(27 + n) < 16384结果是n < 8099。也就是说如果一个列中存储的数据小于8099个字节，那么该列就不会成为溢出列。如果表中有多个列，那么这个值更小。
Dynamic和Compressed行格式
mysql中默认的行格式就是Dynamic。
Dynamic和Compressed行格式和Compact行格式很像，只是在处理行溢出数据上有差异。Dynamic和Compressed行格式不会在记录的真实数据出存放前768个字节，而是将所有字节都存储在其它页面中。
Compressed行格式会采用压缩算法对页面进行压缩，以节省空间。
InnoDB数据页结构
我们已经知道页是InnoDB管理存储空间的基本单位，一个页的大小一般是16KB。InnoDB为了不同的目的设计了许多不同类型的页，我们这里主要关注存储数据记录的页，官方称为索引页。由于还没介绍索引，暂且我们先称为数据页吧。
数据页结构的快速浏览
数据页在结构上可以划分为多个部分，不同的部分有不同的功能，如下图所示：
一个InnoDB数据页被划分为了7个部分，下面大概描述一下这7个部分内容。
记录在页中的存储
用户自己的存储的数据会按照对应的行格式存在User Records中。实际上，新生成的页面是没有User Records的，只有当我们第一次插入数据时，才会从Free Space划一个记录大小的空间给User Records。当Free Space用完之后，就意味着当前的数据页也使用完了。
为了能够将User Records讲清楚，我们先得理解前面提到的记录头信息。
理解记录头信息
先简单介绍一下记录头信息各属性描述：
接下来以page_demo表为例，并插入一些数据,详细介绍记录头信息。
这4条记录在InnoDB中的行格式如下(只展示记录头和真实数据)，列中数据均用十进制表示：
我们对照着这个图来重点介绍几个属性的详细信息：
delete_mask：标记着当前记录是否被删除，0表示未删除，1表示删除。未删除的记录不会立即从磁盘上移除，而是先打上删除标记，所有被删除的记录会组成一个垃圾链表。之后新插入的记录可能会重用垃圾链表占用的空间，因此垃圾链表占用的存储空间也被成为可重用空间。heap_no：表示当前记录在本页中的位置，比如上边4条记录在本页中的位置分别是2、3、4、5。实际上，InnoDB会自动为每页加上两条虚拟记录，一条是最小记录，另一条是最大记录。这两条记录的构造十分简单，都是由5字节大小的记录头信息和8字节大小的固定部分(其实内容就是infimum或者supremum)组成的。这两条记录被单独放在Infimum + Supremum的部分。
从图中我们可以看出来，最小记录和最大记录的heap_no值分别是0和1，也就是说它们的位置最靠前。next_record：表示从当前记录的真实数据到下一条记录的真实数据的地址偏移量。可以简单理解为是一个单向链表，最小记录的下一个是第一条记录，最后一条记录的下一个是最大记录。为了更加形象的展示，我们可以用箭头来替代一下next_record中的地址偏移量：
从图中也能看出来，用户记录实际上按照主键大小正序排序行成一个单向链表。如果从中删除掉一条记录，这个链表也是会跟着变化的，比如我们把第2条记录删掉：
第2条记录并没有从存储空间中移除，而是把该条记录的delete_mask值设置为1。第2条记录的next_record值变为了0，意味着该记录没有下一条记录了。第1条记录的next_record指向了第3条记录。Page Directory(页目录)
我们已经知道，记录在页中按照主键大小正序串联成了一个单链表。如果我们要根据主键查找具体的某条记录应该怎么办，简单的方式是根据链表进行遍历。但是在数据量比较大的情况下，这种方式显然效率太差了。因此mysql使用了Page Directory(页目录)来解决这个问题。
Page Directory(页目录)大致的原理如下：
将所有正常的记录(包括最大和最小记录，不包括标记为已删除的记录)划分为几个组。怎么划分先不关注。每个组的最后一条记录(也就是组内最大的那条记录)的头信息中的n_owned属性表示该组内共有几条记录。将每个组的最后一条记录的地址偏移量单独提取出来按顺序存储到靠近页尾部的地方，这个地方就是所谓的Page Directory。mysql规定对于最小记录所在的分组只能有 1 条记录，最大记录所在的分组拥有的记录条数只能在 1-8 条之间，剩下的分组中记录的条数范围只能在是 4-8 条之间。比方说现在的page_demo表中正常的记录共有18条，InnoDB会把它们分成5组，第一组中只有一个最小记录，如下所示：
通过Page Directory在一个数据页中查找指定主键值的记录的过程分为两步：
通过二分法确定该记录所在的槽，并找到该槽所在分组中主键值最小的那条记录。通过记录的next_record属性遍历该槽所在的组中的各个记录。对于链表的查询性能优化，思想上基本上都是通过二分法实现的。上面介绍的Page Directory，跳跃表和查找树都是如此。
Page Header(页面头部)
Page Header专门用来存储数据页相关的各种状态信息，比如本页中已经存储了多少条记录，第一条记录的地址是什么，页目录中存储了多少个槽等等。固定占用56个字节，各部分字节属性含义如下：
这里只是罗列出来，暂时不需要全部理解。
File Header(文件头部)
File Header是用来描述各种页都适用的一些通用信息的，由以下内容组成：
这里只是罗列出来，暂时不需要全部理解。我们重点关注一下几个属性：
FIL_PAGE_SPACE_OR_CHKSUM当前页面的校验和(checksum)。对于一个很长的字节串来说，我们可以通过某种算法来计算一个比较短的值来代表这个很长的字节串，这个比较短的值就称为校验和。通过校验和可以大幅度提升字符串等值比较的效率。FIL_PAGE_OFFSET每一个页都有一个唯一的页号，InnoDB通过页号来可以定位一个页。FIL_PAGE_TYPE代表当前页的类型，我们前边说过，InnoDB为了不同的目的而把页分为不同的类型。
FIL_PAGE_PREV和FIL_PAGE_NEXT表示本页的上一个和下一个页的页号，各个页通过FIL_PAGE_PREV和FIL_PAGE_NEXT形成双向链表。
File Trailer
mysql中内存和磁盘的基本交互单位是页。如果内存中页被修改了，那么某个时刻一定会将内存页同步到磁盘中。如果在同步的过程中，系统出现问题，就可能导致磁盘中的页数据没能完全同步，也就是发生了脏页的情况。为了避免发生这种问题，mysql在每个页的尾部加上了File Trailer来校验页的完整性。File Trailer由8个字节组成：
