mysql innodb 表_MySQL-InnoDB表

作者：刘仁鹏

参考资料：《MySQL技术内幕 InnoDB存储引擎》

1.索引组织表

在InnoDB中，表都是根据主键顺序组织存放的，这种存储方式的表成为索引组织表。

在InnoDB中，每个表都有主键。如果在创建表时没有显式地定义主键，则InnoDB会按如下方式选择或创建主键：

判断表中是否有非空的唯一索引，如果有，则该列即为主键。如果有多个，选用第一个被声明的主键。

如果不符合上述条件，InnoDB会自动创建一个6字节大小的指针作为主键。

2.InnoDB逻辑存储结构

InnoDB的逻辑存储结构为：表空间->段->区->页->行。页有时也被成为块，如下图所示：

InnoDB逻辑存储结构.png-274.4kB

1.表空间

如果启用了innodb_file_per_table参数，需要注意的是每张表的表空间内存放的只是数据、索引和插入缓冲Bitmap页，其他类的数据，如回滚信息，插入缓冲索引页、系统事务信息，二次写缓冲等还是存放在原来的共享表空间。

2.段

常见的段有数据段、索引段、回滚段等。

因为InnoDB是索引组织的，因此数据即索引，索引即数据。数据段即为B+树的叶子节点，索引段即为B+树的非叶子节点。回滚段较为特殊，后续单独介绍。

3.区

区是由连续页组成的空间，在任何情况下每个区的大小都为1MB。为保证区中页的连续性，InnoDB一次从磁盘申请4~5个区。默认情况下，InnoDB页大小为16K，即一个区中共有64个连续页。

通过参数KEY_BLOCK_SIZE来使用压缩页，或通过innodb_page_size 改变页大小，都会导致一个区中页的数量发生变化。但无论页大小怎么变，区的大小总是1M。

但还存在这样一个问题：在用户启用innodb_file_per_table后，创建的表默认大小是96KB。但区中是64个连续的页，所以创建的表的大小至少是1MB才对啊？其实这是因为在每个段开始时，先用32个页大小的碎片页来存放数据，在使用完这些页后才是64个连续页的申请。这样做的目的是，对于一些小表，或是undo这类的段，可以在开始时申请较少的空间，节省磁盘容量。

4.页

页是InnoDB磁盘管理的最小单位。

从InnoDB1.2.x版本开始，可通过参数innodb_page_size将页的大小设置为4K、8K、16K。若设置完成，则所有表中页的大小都为innodb_page_size，不可以对其再次修改。除非通过mysqldump导入和导出来产生新的库。

InnoDB中，常见的页类型有：

数据页

undo页

系统页

事务数据页

插入缓冲位图页

插入缓冲空闲列表页

未压缩的二进制大对象页

压缩的二进制大对象页

5.行

InnoDB是面向行(row-oriented)的，也就是说数据是按行进行存放的。每个页存放的行记录是有硬性规定的：最多允许存放 16KB/2-200 行的记录，即7992行记录。

3.InnoDB行记录格式

InnoDB提供了Compact和Redundant两种格式来存放行记录数据。其中Redundant是为兼容老版本而保留，建议使用Compact格式。

1.Compact行记录格式

Compact在MySQL5.0中引入，其设计目标是高效地存储数据。

Compact行记录存储方式：

Compact行记录格式.png-101.3kB

第一部分是一个非NULL变长字段长度列表，且其是按列的顺序逆序放置的。

第二部分是NULL标志位，该位指示了改行数据中是否有NULL值。

第三部分是记录头信息，固定占用5字节(40位)，每位含义如下：

Compact记录头信息.png-196.5kB

最后的部分是实际存储每个列的数据。

需要注意的是：

NULL除了占有NULL标志位，实际存储不占任何空间。

每行数据除了用户定义的列之外，还有两个隐藏列，事务ID列和回滚指针列。分别为6字节和7字节的大小。若InnoDB表没有定义主键，每行还会增加一个6字节的rowid列。

固定长度CHAR字段在未能完全占用其长度空间时，会用0x20来进行填充。

记录头信息的最后两个字节代表next_recorder，代表下一条记录的偏移量，所以InnoDB在页内部是通过一种链表的结构来串连各个行记录的。

2.Redundant行记录格式

Redundant是MySQL5.0版本之前InnoDB的行记录格式，其存在是为了兼容老版本的页格式。

Redundant行记录存储方式：

Redundant行记录格式.png-178.3kB

第一部分是一个字段长度偏移列表，同样是按列的顺序逆序放置的。

第二部分是记录头信息，不同于Compact，Redundant占用6字节(48位)，每位含义如下：

Redundant记录头信息.png-198.9kB

其中n_fields值代表一行中列的数量，占用10位。这也解释了为什么MySQL 一行支持的最多列数为1023。

需要注意的是：

对于NULL值的处理，Redundant和Compact非常不同：对于VARCHAR类型的NULL值，Redundant同样不占用任何空间，但CHAR类型的NULL值需要占用最大值字节数大小的空间。

3.行溢出数据

InnoDB可以将一条记录中的某些数据存储在真正的数据页面之外。

是否溢出与列类型是否为BLOB等大对象列类型并无直接关系。而是根据“保证一个页至少能存放两条记录”的标准来判断的。如果VERCHAR类型的列长度过长导致一页只能存储一条记录，则也会被放到Uncompressed BLOB Page(行溢出数据页)。之所以有这个标准的原因，是因为如果不能保证如此，那B+Tree就是去意义变成链表了。

InnoDB能存放VARCHAR类型的最大长度为65532字节 (注意并非65535，这其中还有其他开销)。另外要注意，VARCHAR(N)中的N指的是字符的长度而非字节。另外，MySQL手册中定义的65535字节长度是指所有VARCHAR列的长度总和。

当发生行溢出时，数据页中值保存了列的前768字节的前缀数据，之后是偏移量，指向行溢出页。如下图所示：

行溢出数据的存储.png-27.2kB

4.Compressed和Dynamic行记录格式

从InnoDB1.0.x开始引入了新的文件格式(可理解为页格式)：Barracuda。而之前的文件格式被称为Antelope，Barracuda包含了Antelope：

文件格式.png-59kB

新的两种行记录格式对于存放在BLOB中的数据采用了完全的行溢出方式，在数据页中只存放20个字节的指针，实际的数据都存放子啊OffPage中。而之前的两种行记录格式都是会存放768个前缀字节。新的行溢出方式如下：

B行溢出方式.png-23.5kB

Compressed行记录格式的另一个功能就是：存储在其中的行数据会以zlib的算法进行压缩。因此对于BLOB、TEXT、VARXCHAR这些大长度类型的数据能够非常有效的存储。

5.CHAR的行存储结构

从MySQL4.1开始，CHAR(N)中的N指的是字符的长度，而不是之前版本的字节长度。也就是说在不同字符集下，CHAR类型列内部存储的可能不是定长的数据。

另外由于多字节的字符编码，不同字符的长度可能不同，所以CHAR类型不再代表固定长度的字符串了。因此，对于多字节字符编码的CHAR类型的存储，InnoDB在内部将其视为变长字符类型。这也就意味着在变长长度列表中会记录CHAR数据类型的长度。只是对于未能占满长度的字符还是填充0x20。

4.InnoDB数据页结构

通过前面内容我们已了解到，页是InnoDB管理数据库的最小磁盘单位。

InnoDB数据页由以下七部分组成：

InnoDB数据页结构.png-310.3kB

1.File Header：文件头

File Header用来记录页的一些头信息，共由如下8部分组成，共占用38字节：

FileHeader.png-469.4kB

InnoDB页的类型：

InnoDB页类型.png-272.3kB

2.Page Header：页头

该部分用来记录数据页的状态信息，由14个部分组成，共56字节：

PageHeader.png-479.8kB

PageHeader2.png-116.1kB

3.Infimum和Supremum Record

在InnoDB中，每个数据页都有两个虚拟的行记录，用来限定记录的边界。

Infimum记录是比该页中任何主键值都要小的值。

Supremum指比任何可能大的值还要大的值。

这两个值在页创建时被建立，且在任何情况下都不会被删除。

示意图如下：

record.png-184.8kB

4.User Record和Free Space

User Record，用户记录，即行记录。

Free Space，空闲空间。是个链表数据结构。在一条记录被删除后，该空间会被加入到空闲链表中。

5.Page Directory：页目录

Page Directory中存放了记录的相对位置，有时将这些记录指针称为Slots(槽)或Directory Slots(目录槽)。

InnoDB中并不是每个记录都拥有一个槽，InnoDB的槽是一个稀疏目录，即一个槽中可能包含多个记录。当记录被插入或删除时，需要对槽进行分裂或平衡的维护操作。

在槽中记录按照索引键信息顺序存放，这样可以利用二叉查找迅速找到记录的指针。

需要注意的是：B+树索引本身并不能找到具体的一条记录，能找到只是该记录所在的页。数据库把页载入到内存，然后通过Page Directory再进行二叉查找。只不过二叉查找的时间复杂度很低，同时在内存中查找很快，因此通常忽略这部分时间。

6.File Trailer：文件结尾信息

为了检测页是否已完整地写入磁盘(如写入时可能发生磁盘损坏、机器关机等)，InnoDB设置了File Trailer来保证页的完整性。

end