InnoDB存储结构二

InnoDB线程模型

IO Thread

在InnoDB中使用了大量的AIO（Async IO）来做读写处理，这样可以极大提高数据库的性能。在
InnoDB1.0版本之前共有4个IO Thread，分别是write，read，insert buffer和log thread，后来
版本将read thread和write thread分别增大到了4个，一共有10个了。

• read thread ： 负责读取操作，将数据从磁盘加载到缓存page页。4个
• write thread：负责写操作，将缓存脏页刷新到磁盘。4个
• log thread：负责将日志缓冲区内容刷新到磁盘。1个
• insert buffer thread ：负责将写缓冲内容刷新到磁盘。1个

show engine  innodb status \G;

Purge Thread

事务提交之后，其使用的undo日志将不再需要，因此需要Purge Thread回收已经分配的undo
页。
show variables like ‘%innodb_purge_threads%’;

4个线程来做，大于0表示启用，0表示禁用

Page Cleaner Thread

作用是将脏数据刷新到磁盘，脏数据刷盘后相应的redo log也就可以覆盖，即可以同步数据，又能
达到redo log循环使用的目的。会调用write thread线程处理。
show variables like ‘%innodb_page_cleaners%’;

调用了ioThread中的writeThread，来完成

Master Thread

Master thread是InnoDB的主线程，负责调度其他各线程，优先级最高。作用是将缓冲池中的数
据异步刷新到磁盘 ，保证数据的一致性。包含：脏页的刷新（page cleaner thread）、undo页
回收（purge thread）、redo日志刷新（log thread）、合并写缓冲等。内部有两个主处理，分别
是每隔1秒和10秒处理

• 每1秒的操作：
  刷新日志缓冲区，刷到磁盘
  合并写缓冲区数据，根据IO读写压力来决定是否操作
  刷新脏页数据到磁盘，根据脏页比例达到75%才操作（innodb_max_dirty_pages_pct，innodb_io_capacity）

• 每10秒的操作：
  刷新脏页数据到磁盘
  合并写缓冲区数据
  刷新日志缓冲区
  删除无用的undo页-一次删除300
  

InnoDB数据文件

InnoDB文件存储结构

InnoDB数据文件存储结构：
分为一个ibd数据文件–>Segment（段）–>Extent（区）–>Page（页）–>Row（行）

• Tablesapce
  表空间，用于存储多个ibd数据文件，用于存储表的记录和索引。一个文件包含多个段。

• Segment
  段，用于管理多个Extent，分为数据段（Leaf node segment）、索引段（Non-leaf node
  segment）、回滚段（Rollback segment）。一个表至少会有两个segment，一个管理数
  据，一个管理索引。每多创建一个索引，会多两个segment。

• Extent
  区，一个区固定包含64个连续的页，大小为1M。当表空间不足，需要分配新的页资源，不会
  一页一页分，直接分配一个区。

• Page
  页，用于存储多个Row行记录，大小为16K。包含很多种页类型，比如数据页，undo页，系
  统页，事务数据页，大的BLOB对象页。

• Row
  行，包含了记录的字段值，事务ID（Trx id）、滚动指针（Roll pointer）、字段指针（Field
  pointers）等信息
  。
  Page是文件最基本的单位，无论何种类型的page，都是由page header，page trailer和page
  body组成。如下图所示
  

InnoDB文件存储格式

一般情况下，如果row_format为REDUNDANT、COMPACT，文件格式为Antelope；如果
row_format为DYNAMIC和COMPRESSED，文件格式为Barracuda

通过 information_schema 查看指定表的文件格式

select * from information_schema.innodb_sys_tables;

在创建表和索引时，文件格式都被用于每个InnoDB表数据文件（其名称与*.ibd匹配）。修改文件
格式的方法是重新创建表及其索引，最简单方法是对要修改的每个表使用以下命令：

ALTER TABLE 表名 ROW_FORMAT=格式类型;

File文件格式（File-Format）

在早期的InnoDB版本中，文件格式只有一种，随着InnoDB引擎的发展，出现了新文件格式，用于
支持新的功能。目前InnoDB只支持两种文件格式：Antelope 和 Barracuda。

• Antelope: 先前未命名的，最原始的InnoDB文件格式，它支持两种行格式：COMPACT和
  REDUNDANT，MySQL 5.6及其以前版本默认格式为Antelope。

• Barracuda: 新的文件格式。它支持InnoDB的所有行格式，包括新的行格式：COMPRESSED
  和 DYNAMIC。

通过innodb_file_format 配置参数可以设置InnoDB文件格式，之前默认值为Antelope，5.7版本
开始改为Barracuda。

ROW格式（Row_format）

表的行格式决定了它的行是如何物理存储的，这反过来又会影响查询和DML操作的性能。如果在
单个page页中容纳更多行，查询和索引查找可以更快地工作，缓冲池中所需的内存更少，写入更
新时所需的I/O更少。
InnoDB存储引擎支持四种行格式：REDUNDANT、COMPACT、DYNAMIC和COMPRESSED。

DYNAMIC和COMPRESSED新格式引入的功能有：数据压缩、增强型长列数据的页外存储和大索引前缀。每个表的数据分成若干页来存储，每个页中采用B树结构存储；

如果某些字段信息过长，无法存储在B树节点中，这时候会被单独分配空间，此时被称为溢出页，
该字段被称为页外列

• REDUNDANT 行格式
  使用REDUNDANT行格式，表会将变长列值的前768字节存储在B树节点的索引记录中，其余的存储在溢出页上。对于大于等于786字节的固定长度字段InnoDB会转换为变长字段，以便能够在页外存储

• COMPACT 行格式
  与REDUNDANT行格式相比，COMPACT行格式减少了约20%的行存储空间，但代价是增加了某些操作的CPU使用量。如果系统负载是受缓存命中率和磁盘速度限制，那么COMPACT格式可能更快。如果系统负载受到CPU速度的限制，那么COMPACT格式可能会慢一些。

• DYNAMIC 行格式
  使用DYNAMIC行格式，InnoDB会将表中长可变长度的列值完全存储在页外，而索引记录只包含指向溢出页的20字节指针。大于或等于768字节的固定长度字段编码为可变长度字段。DYNAMIC行格式支持大索引前缀，最多可以为3072字节，可通过innodb_large_prefix参数控制。

• COMPRESSED 行格式
  COMPRESSED行格式提供与DYNAMIC行格式相同的存储特性和功能，但增加了对表和索引数据压缩的支持。

 select * fro information_schema.innodb_sys_tables;