注：文章中的“列”和“字段”基本可以等价，“记录”和“行”基本可以等价，为了易于理解选择代替，但发现不够严谨，在此声明

compact行格式是mysql中InnoDB存储引擎存储数据使用的一种行格式，InnoDB存储引擎每次从磁盘中读取数据到内存中的基本单位是页（不是最小单位）,而每一页中的数据就是很多行构成的，每一行数据都有存储数据的格式，叫做行格式，COMPACT行格式就是InnoDB存储引擎中的行格式。只不过COMPACT行格式是较老一些的行格式，由REDUNDANT行格式衍生而来，如今常用的行格式为DYNAMIC和COMPRESSED两种，其中DYNAMIC是5.7版本默认的行格式，因为DYNAMIC是由COMPACT行格式衍生而来，所以了解COMPACT行格式很有必要。

直接上图（图片来源：小林coding）

从图中可以直观地看到一行数据可分为额外信息和真实数据两部分

记录的额外信息为了更好的管理数据而添加的一些信息，分为变长字段长度列表，NULL值列表和记录头信息三部分。

1.记录的额外信息

（1）变长字段长度列表：

我们知道，MySQL支持一些可变长度的数据类型，例如VARCHAR，TEXT，BLOB类型。变长数据类型的长度是不固定的，所以一行数据如果有变长字段的话，要有对这个变长字段实际长度的记录，而变长字段长度列表就是记录变长字段的实际长度的。在COMPACT行格式中，各个变长字段的实际长度会逆序存储在变长字段长度列表中。

假如一个表中三个varchar类型的字段，假如其中一行的长度分别10，02，09，那么他们在变长字段长度列表中的储存顺序就是09，02，10。当然，如果该表中的每一个字段的数据类型都是定长的数据类型，那么这个变长字段长度列表就不会存在。

（2）NULL值列表：

我们知道，字段值可以为NULL，如果一个字段的类型是CHAR(10)，而在某一行中这个字段值为NULL，如果把这个NULL存储在真实数据中对应的该字段所对应的10个CHAR类型的空间中是很浪费的，所以COMPACT行格式把一行数据中字段值为NULL的字段统一记录起来存储在NULL值列表中。

首先要统计表中允许存储NULL值的字段有哪些，因为有些被NOT NULL限制的字段是不允许为NULL的，所以在统计的时候不会把这些字段放进去。与变长字段长度列表同理，如果表中的每一个字段都是不能为NULL的，那一行数据中的NULL值列表也就不存在了。

存储方式和变长字段长度列表的存储方式非常类似，都是以逆序的顺序存储，例如一行数据中有四个字段name,phone,age,grade，其中name,phone,age三个字段为NULL，NULL值列表中的记录就会是00000111,1为NULL，0不为NULL，NULL值列表如果存在的话默认的长度为8个bit（是bit，不是byte！）8个bit在硬件中对应的就是8个二进制位,每一个字段记录对应一个二进制位

如果说一个表中可为NULL的字段数量多于8个，那么这个NULL值列表的长度将会变为16个bit位。

（3）记录头信息：

记录头信息由固定的5个字节，也就是40个bit位组成，用于描述一些属性，组成如下

预留位1和2没有使用，如果你了解InnoDB存储引擎的数据结构的话你会知道这些描述的意义，正是对InnoDB的聚簇索引的实现起到了积极作用，有兴趣的可以自行了解。

2. 记录的真实信息

对于一张表来说，除了记录真实的字段值的数据外，还会有row_id，trx_id，roll_pointer。

（1）row_id：

我们知道InnoDB存储引擎存储数据由一个B+树完成，而形成B+树最终要的就是要有一个可以作为主键的主键值，这个值应该是NOT NULL,UNIQUE（非空唯一）的，但是如果我们创建的表没有适合用来作为主键的字段，那么InnoDB就会隐式的添加一个字段，这个字段来作为主键值构造B+树，而这个隐式的数据就存放在row_id这个位置中，所以row_id字段不是必须的。

（2）trx_id：

这个字段记录事务id，表示这个数据是由哪个事务生成的，InnoDB存储引擎支持事务，这也是InnoDB安全性高的主要原因，这个字段必须存在。

（3）roll_pointer:

这个字段存储的是一个地址，该地址指向这行数据修改前的记录，因为每次对某条聚簇索引的数据进行改动时，都会把旧版本的记录写入到undo日志中，而这个隐藏字段的指针指向旧版本记录，也叫回滚指针。这也是事务的内容，也是InnoDB安全性高的原因之一。这个列也是必须存在的。

（4）存储真实数据的字段，里面的数据叫做字段值。

这个位置是COMPACT行格式与DYNAMIC和COMPRESSED行格式的主要区别所在，InnoDB数据交互的基本单位是页，而一个页的大小一般是16KB，假如我们添加了一行数据，这个数据中的一个字段值位65532B，就是64KB，很显然，这大于一个页所能存储的最大数据量，那一个页一行数据都存储不了很尴尬啊，所以在COMPACT和更老一点的REDUNDANT行格式中，对于占用空间非常多的列，在记录真实数据的地方只会存储该列的一部分数据，而把剩余的数据存储在其他页面中，这些存储其他数据的页叫做溢出页。具体的存储方式是，将前768个字节的数据存储在当前页面，然后用20个字节存储存储溢出数据的地址。这个需要用到溢出页存储数据的这一列也叫溢出列（off-page列）。

我们知道了COMPACT和REDUNDANT行格式对溢出数据的处理，那DYNAMIC和COMPRESSED行格式是怎么做的呢？他们不会在记录真实数据的地方存那768字节，而是把该溢出列的所有数据都存储在溢出页当中，在存储真实数据的地方只用20个字节去记录这些溢出数据的地址，而COMPRESSED比DYNAMIC会多做一步：采用压缩算法对页面进行压缩，以节省空间。

到这里，还有最后一个问题没有结局，那就是，到底多大才算是大呢，什么时候才溢出呢？

MySQL中规定一个页中至少存放两条数据，而一页的大小是16KB，每一页中都要用132字节存储一些额外信息（就像COMPACT行格式中记录额外信息的部分），然后每一行数据，有27字节是记录额外信息的，就是上面讲到的那些东西。我们假设一行数据能够存储真实数据的字节数为n，根据MySQL的规定，想要发生溢出就要满足下面的公式

132+2×（27+n）>=16384

通过观察这个公式，我们很容易就能看出出，这就是一个页的大小，假如一个页中只有两条数据，这个n值要大于8099才会溢出。我们不用关注这个临界点是多大，只要记着某个列中存储的数据所占用的字节数非常多时，该列就可能为溢出列。

总结：

到这里COMPACT行格式基本讲完了，我们要知道的是页是InnoDB中磁盘和内存交互的基本单位，每一个页的大小为16KB，当中的数据是一行一行的，行以不同的行格式存储数据，如今默认为DYNAMIC行格式，数据太大的话就会溢出，溢出的数据存储在溢出页中。