Innodb存储表结构

索引组织表(index organized table)

在InnoDB存储引擎中，表都是根据主键顺序组织存放的，这种存储方式的表叫索引组织表。在InnoDB存在引擎表中，每张表都有个主键(Primary key)，如果在创建表时没有显示定义主键，则会按照如下方式选择或者创建主键：

(1) 判定是否有非空的唯一索引(unique not null)，如果有则该列即为主键。若果有多个，则选择建表是第一个定义的非空位于索引为主键。注意:主键的选择根据的是定义索引的顺序，而不是建表时的列的顺序。

(2) 如果不存在唯一索引，InnoDB存储引擎字段创建一个6字节大小的指针(仅内部可见)。

InnoDB逻辑存储结构

在InnoDB存储引擎中，所有的数据都被逻辑地存放在一个空间中，称之为表空间(tablespace)。表空间又由段(segment)、区(extent)、页(page)组成。InnoDB存储引擎的逻辑存储结构如下图。

表空间 可以看见InnoDB存储引擎逻辑结构的最高层，所有的数据都存放在表空间中。表空间又分为独立表空间和共享表空间。通过参数innodb_file_per_table参数来决定使用何种类型的表空间。但是需要注意的是独立表空间内只存放数据、索引和插入缓冲页，其他的数据，如回滚(undo)信息、插入缓冲索引页、系统事务信息、二次写缓冲(double write buffer)等还是放置在原来的共享表空间中。

段表空间由各个段组成。常见的段有数据段、索引段、回滚段等。InnoDB存储引擎是索引组织表，因此数据即索引，索引即数据。数据段即为B+树的叶子点(leaf node segment)，索引段为B+数据的非索引节点(non-leaf node segment)。回滚段比较特殊以后在介绍。段都是引擎自身管理的。

区区是由连续页组成的空间。InnoDB存储引擎页的大小为16KB，一个区有64个连续的页组成，所以每个区的大小都是1MB。参数innodb_page_size可设置页的大小4K、8K，但是，不论页的大小怎么变化，区的大小不变1M。但是有这样一个问题：在开启独立表空间之后，创建的表默认大小是96K，区中是64个连续的页，创建的表空间应该是1M才对呀？这是因为在每个段的开始时，先用32个页大小的碎片页(fragment page)来保存数据，在使用完这些页之后才是64个连续的页的申请。这样做是对于一些小表或者undo这类的段，可以在开始时申请较少的空间，节省磁盘容量的开销。

页页是InnoDB磁盘管理的最小单位。默认大小为16K，可以通过innodb_page_size将页的大小设置为4K、8K、16K，则所有表中页的大小都为设置值，不可以对其再次修改。除非通过mysqldump导入和导出操作来产生新的库。常见的页的类型有:数据页(B-tree Node)、undo页(unod Log Page)、系统页(System Page)、事务数据页(Transaction system Page)、插入缓冲空闲列表页(Insert Buffer Free List)、未压缩的二进制大对象页(Uncompressed BLOB Page)、压缩的二进制对象页(compressed BLOB Page)。

行 InnoDB存储引擎是面向行的(row-oriented)，也就是说数据是按行进行存放的。每个页存放的行记录也是有硬性定义的，最多运行存放（16K/2-200）行的记录，即7992行记录。

InnoDB物理存储结构

InnoDB表由共享表空间（ibdata1），redo日志文件组（ib_logfile0，ib_logfile1），表结构定义文件（表名.frm）组成。当开启独立表空间时，还有以表名.ibd的文件，存储数据，索引，插入缓存列。

InnoDB行记录格式

InnoDB存储引擎的记录是以行的形式存储的，这就表明页中保存着表中一行行的数据。其类型有REDUNDANT、 COMPACT、COMPRESS、DYNAMIC四种。可以通过show table status。

COMPACT 在MySQL 5.0中引入，其设计目标是高效的存储数据。也就是一个页中存放的行数据越多，其性能越高。compact行记录的存放方式:

第一部分是一个非NULL变长字段长度列表（字节数与非NULL变长字段数相同），且其是按列的顺序逆序放置的。
第二部分是NULL标志位(1个bit表示对应列的NULL)，该位指示了改行数据中是否有NULL值。
第三部分是记录头信息，固定占用5字节（40位），每位含义如下：

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

需要注意的是：

NULL除了占有NULL标志位，实际存储不占任何空间。
每行数据除了用户定义的列之外，还有两个隐藏列，事务ID列和回滚指针列。分别为6字节和7字节的大小。若InnoDB表没有定义主键，每行还会增加一个6字节的rowid列。
固定长度CHAR字段在未能完全占用其长度空间时，会用0x20来进行填充。
记录头信息的最后两个字节代表next_recorder，代表下一条记录的偏移量，所以InnoDB在页内部是通过一种链表的结构来串连各个行记录的。

REDUNDANT

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

第一部分是一个字段长度偏移列表，同样是按列的顺序逆序放置的。
第二部分是记录头信息，不同于Compact，Redundant占用6字节（48位），每位含义如下：

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

需要注意的是：

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

行溢出数据

InnoDB可以将一条记录中的某些数据存储在真正的数据页面之外。
是否溢出与列类型是否为BLOB等大对象列类型并无直接关系。而是根据“保证一个页至少能存放两条记录”的标准来判断的。如果VERCHAR类型的列长度过长导致一页只能存储一条记录，则也会被放到Uncompressed BLOB Page（行溢出数据页）。之所以有这个标准的原因，是因为如果不能保证如此，那B+Tree就是去意义变成链表了。
InnoDB能存放VARCHAR类型的最大长度为65532字节 （注意并非65535，这其中还有其他开销）。另外要注意，VARCHAR(N)中的N指的是字符的长度而非字节。另外，MySQL手册中定义的65535字节长度是指所有VARCHAR列的长度总和。
当发生行溢出时，数据页中值保存了列的前768字节的前缀数据，之后是偏移量，指向行溢出页。如下图所示：

Compressed和Dynamic行记录格式

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

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

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

CHAR的行存储结构

从MySQL4.1开始，CHAR(N)中的N指的是字符的长度，而不是之前版本的字节长度。也就是说在不同字符集下，CHAR类型列内部存储的可能不是定长的数据。
另外由于多字节的字符编码，不同字符的长度可能不同，所以CHAR类型不再代表固定长度的字符串了。因此，对于多字节字符编码的CHAR类型的存储，InnoDB在内部将其视为变长字符类型。这也就意味着在变长长度列表中会记录CHAR数据类型的长度。只是对于未能占满长度的字符还是填充0x20。

InnoDB数据页结构

通过前面内容我们已了解到，页是InnoDB管理数据库的最小磁盘单位。
InnoDB数据页由以下七部分组成：

File Header：文件头

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

InnoDB页的类型：

Page Header：页头

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

Infimum和Supremum Record

在InnoDB中，每个数据页都有两个虚拟的行记录，用来限定记录的边界。
Infimum记录是比该页中任何主键值都要小的值。
Supremum指比任何可能大的值还要大的值。
这两个值在页创建时被建立，且在任何情况下都不会被删除。
示意图如下：

User Record和Free Space

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

Page Directory：页目录

Page Directory中存放了记录的相对位置，有时将这些记录指针称为Slots（槽）或Directory Slots（目录槽）。
InnoDB中并不是每个记录都拥有一个槽，InnoDB的槽是一个稀疏目录，即一个槽中可能包含多个记录。当记录被插入或删除时，需要对槽进行分裂或平衡的维护操作。
在槽中记录按照索引键信息顺序存放，这样可以利用二叉查找迅速找到记录的指针。
需要注意的是：B+树索引本身并不能找到具体的一条记录，能找到只是该记录所在的页。数据库把页载入到内存，然后通过Page Directory再进行二叉查找。只不过二叉查找的时间复杂度很低，同时在内存中查找很快，因此通常忽略这部分时间。

File Trailer：文件结尾信息

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

MySQL-InnoDB表 - 简书

MySQL InnoDB存储引擎之表(一)_chenlvzhou的专栏-CSDN博客