MySQL-InnoDB表


作者:刘仁鹏
参考资料:《MySQL技术内幕 InnoDB存储引擎》


1.索引组织表

  • 在InnoDB中,表都是根据主键顺序组织存放的,这种存储方式的表成为索引组织表
  • 在InnoDB中,每个表都有主键。如果在创建表时没有显式地定义主键,则InnoDB会按如下方式选择或创建主键:
  1. 判断表中是否有非空的唯一索引,如果有,则该列即为主键。如果有多个,选用第一个被声明的主键。
  2. 如果不符合上述条件,InnoDB会自动创建一个6字节大小的指针作为主键。

2.InnoDB逻辑存储结构

  • InnoDB的逻辑存储结构为:表空间->段->区->页->行。页有时也被成为块,如下图所示:
    MySQL-InnoDB表_第1张图片
    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中,常见的页类型有:
  1. 数据页
  2. undo页
  3. 系统页
  4. 事务数据页
  5. 插入缓冲位图页
  6. 插入缓冲空闲列表页
  7. 未压缩的二进制大对象页
  8. 压缩的二进制大对象页

5.行

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

3.InnoDB行记录格式

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

1.Compact行记录格式

  • Compact在MySQL5.0中引入,其设计目标是高效地存储数据。
  • Compact行记录存储方式:


    Compact行记录格式.png-101.3kB
    Compact行记录格式.png-101.3kB
  1. 第一部分是一个非NULL变长字段长度列表,且其是按列的顺序逆序放置的。
  2. 第二部分是NULL标志位,该位指示了改行数据中是否有NULL值。
  3. 第三部分是记录头信息,固定占用5字节(40位),每位含义如下:


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

2.Redundant行记录格式

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


    Redundant行记录格式.png-178.3kB
    Redundant行记录格式.png-178.3kB
    1. 第一部分是一个字段长度偏移列表,同样是按列的顺序逆序放置的。
    2. 第二部分是记录头信息,不同于Compact,Redundant占用6字节(48位),每位含义如下:


      MySQL-InnoDB表_第3张图片
      Redundant记录头信息.png-198.9kB
    • 其中n_fields值代表一行中列的数量,占用10位。这也解释了为什么MySQL 一行支持的最多列数为1023
  • 需要注意的是:
  1. 对于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字节的前缀数据,之后是偏移量,指向行溢出页。如下图所示:
    MySQL-InnoDB表_第4张图片
    行溢出数据的存储.png-27.2kB

4.Compressed和Dynamic行记录格式

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


    MySQL-InnoDB表_第5张图片
    文件格式.png-59kB
  • 新的两种行记录格式对于存放在BLOB中的数据采用了完全的行溢出方式,在数据页中只存放20个字节的指针,实际的数据都存放子啊OffPage中。而之前的两种行记录格式都是会存放768个前缀字节。新的行溢出方式如下:


    MySQL-InnoDB表_第6张图片
    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数据页由以下七部分组成:


    MySQL-InnoDB表_第7张图片
    InnoDB数据页结构.png-310.3kB

1.File Header:文件头

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


    MySQL-InnoDB表_第8张图片
    FileHeader.png-469.4kB
  • InnoDB页的类型:


    MySQL-InnoDB表_第9张图片
    InnoDB页类型.png-272.3kB

2.Page Header:页头

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


    MySQL-InnoDB表_第10张图片
    PageHeader.png-479.8kB

    MySQL-InnoDB表_第11张图片
    PageHeader2.png-116.1kB

3.Infimum和Supremum Record

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


    MySQL-InnoDB表_第12张图片
    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

你可能感兴趣的:(MySQL-InnoDB表)