表就是关于特定实例的数据集合，这也是关系型数据库模型的核心。
4.1 索引组织表
在InnoDB存储引擎中，表都是根据主键顺序组织存放的，这种存储方式的表称为索引组织表（index organized table）。在InnoDB存储引擎表中，每张表都有个主键（primary key），如果在创建表时没有显式的定义主键，则InnoDB按照如下方式来选择或者创建主键
首先判断表中是否存在有非空的唯一索引，如果有，则该列即为主键
如果不符合上述条件，InnoDB存储引擎自动创建一个6字节大小的指针。
当表中有多个非空的唯一索引时，InnoDB将选择建表时第一个定义的非空唯一索引为主键。
4.2 InnoDB 逻辑存储结构
所有数据都被逻辑地存放在一个空间中，称之为表空间（tablespace）。表空间又由段（segment）、区（extent）、页（page）组成。页在一些文档中有时也称为块（block）。
4.2.1 表空间
所有的数据都存放在表空间中
4.2.2 段
表空间是有各个段组成的，常见的段有数据段、索引段、回滚段等，因为InnoDB存储引擎表是索引组织的，因此数据即索引，索引即数据。那么数据段即为B+树的叶子节点，索引段即为B+树的非索引节点
4.2.3 区
区是由连续也组成的空间，在任何情况下大小都是1MB。为了保证区中页的连续性，InnoDB存储引擎一次从磁盘申请4~5个区。在默认的情况下，InnoDB存储引擎页的大小为16KB，即一个区中一共有64个连续的页。
InnoDB1.0.x版本开始引入了压缩页，即每个页的大小可以通过参数KEY_BLOCK_SIZE设置为2K，4K，8K，因此每个区对应的页数量就应该是512,256,128
InnoDB1.2.x版本新增了参数innodb_page_size，通过该参数可以将默认页的大小设置为4K，8K，但是页中的数据库不是压缩。这是区中也的数量同样是256、128，总之，不论页的大小怎样变化，区的大小总是为1M。
4.2.4 页
页是InnoDB磁盘管理的最小单位。在InnoDB存储引擎中，常见的页类型有
- 数据页
- undo页
- 系统页
- 事务数据页
- 插入缓冲位图页
- 插入缓冲空闲列表页
- 未压缩的二进制大对象页
- 压缩的二进制大对象页
4.2.5 行
InnoDB存储引擎是面向列的（row-oriented），也就是说数据是按行进行存放的。每个页存放的行记录也是有硬性定义的，最多允许存放16KB/2 - 200 行的记录，即7992行的记录
4.3 InnoDB行记录格式
在InnoDB1.0.x版本之前，InnoDB存储引擎提供了Compact和Redundant两种格式来存放行记录
4.3.1 Compact行记录格式
Compact行记录格式的首部是一个非NULL变长字段长度列表，并且其是按照列的顺序逆序放置的，若列的长度小于255字节，用1字节表示，若大于255字节，用2字节表示。变长字段的长度最大不可以超过两字节，这是因为MySQL数据库中VARCHAR类型的最大长度限制为65535。
变长字段之后的第二个部分是NULL标志位，该位指示了该行数据是否有NULL值，有则用1表示。该部分占1字节
接下来是记录头信息（record header），固定占用5字节
最后的部分就是实际存储每个列的数据。特别注意的是，NULL不占该部分任何空间，即NULL除了占有NULL标志位，实际存储不占有任何空间。另外有一点需要注意的是，每行数据除了用户定义的列外，还有两个隐藏列，事务ID列和回滚指针列，分别为6字节和7字节的大小。若InnoDB表没有定义主键，每行还会增加一个6字节的rowid列。
不管是CHAR类型还是VARCHAR类型，在compact格式下NULL值不占任何存储空间
4.3.2 Redundant行记录格式
Redundant是MySQL5.0版本之前InnoDB的行记录存储方式，MySQL5.0支持Redundant是为了兼容之前版本的格式
Redundant行记录格式的首部是一个字段长度偏移列表，同样是按照列的顺序逆序放置的。若列的长度小于255字节，用1字节表示，若大于255字节，用2字节表示。第二部分为记录头信息（record header），占用6字节（48位）
n_fields值代表一行中列的数量，占用10位。同时这很好的解释了为什么MySQL数据库一行支持最多的列为1023.
对于VARCHAR类型的NULL值，Redundant行记录格式同样不占用任何存储空间，而CHAR类型的NULL值需要占用空间
4.3.3 行溢出数据
InnoDB存储引擎可以将一条记录中的某些数据存储在真正的数据页面之外。一般认为BLOB，LOB这类的大对象类型的存储会把数据存放在数据页面之外。但是，这种理解有点偏差，BLOB可以不将数据放在溢出页面，而且即便是VARCHAR列数据类型，依然有可能被存放为行溢出数据。
InnoDB存储引擎并不支持 65535 长度的VARCHAR。这是因为还有别的开销，通过实际测试发现能存放VARCHAR类型的最大长度为65532。如果没有讲SQL MODE设置为严格模式，VARCHAR的长度为65535是可以建表的，不过MySQL数据库会抛出一个warning，warning提示这次可以创建是因为MySQL数据库自动将VARCHAR类型转换成了TEXT类型。上述讲的创建VARCHAR类型长度为 65532 的表，其字符类型是latin1（ISO-8859-1，8位字符集），如果换成GBK（16位字符集）或者UTF-8（utf编码是不定长编码，每一个字符的长度从1-6个字节不等），即使创建列的VARCHAR长度是 65532 ，也会提示报错，说明VARCHAR(N)中的 N 指的是字节长度而不是字符长度（4.X之前按字节，5.0之后按字符）。特别需要注意的是，MySQL官方手册中定义的 65535 长度是指所有 VARCHAR列的长度总和，而不是单个列的，如果列的长度总和超出这个长度，依然无法创建。
InnoDB存储引擎的页为16KB，即16384字节，怎么能存放65535 字节呢？因此一般情况下，InnoDB存储引擎的数据都是存放在页类型为B-tree node中。但是当发生行溢出时，数据存放在页类型为Uncompress BLOB页中。
那么多长的VARCHAR是可以保存在单个数据页中的，从多长开始又会保存在BLOB页呢？InnoDB存储引擎是索引组织的，即B+树的结构，这样每个页中至少应该有两条行记录，否则变成了链表，失去了B+ 树的意义。因此，如果页中只能存放下一条记录，那么InnoDB存储引擎会自动将行数据存放到溢出页中。经过多次测试，发现这个阈值是 8098 。
对于TEXT和BLOB的数据类型，用户总是以为它们是存放在Uncompressed BLOB page中的，其实不然。放在数据页还是BLOB页和前面说的VARCHAR一样，至少能保证一个页能存放两条记录。
4.3.4 Compressed和Dynamic行记录格式
InnoDB1.0.x版本开始引入了新的文件格式，以前支持的Compact和Redundant格式称为Antelope文件格式，新的文件格式称为Barracuda文件格式。Barracuda文件格式下拥有两种新的行记录格式：Compressed和Dynamic。
新的两种记录格式对于存放在BLOB中数据采用完全的行溢出方式，在数据页中只存放20个字节的指针，实际的数据都存放在Off Page中，而之前的Compact和Redundant两种格式会存放768个前缀字节
