MySQL5.7与InnoDB架构

一、网络连接层

1.1、客户端连接器

提供MySQL与应用间的连接功能

二、服务层

2.1、连接池

存储和管理应用与MySQL间的连接

2.2、系统管理和控制工具

主要功能：数据备份、安全管理、集群管理等

2.3、SQL接口

接收客户端发送的SQL指令，并返回相应的结果

2.4、解析器

将SQL解析成“解析树",并检查解析树的合法性

2.5、查询优化器

将“解析树”转换为执行计划，并与存储引擎交互

2.6、缓存

用于提高SQL查询效率，如果命中缓存则直接返回结果。缓存主要包括：表缓存、记录缓存、权限缓存、引擎缓存等

三、存储引擎层

MySQL中常见存储引擎为：MyISAM和InnoDB。用于对数据进行存储和提取，与底层文件系统交互。MySQL的存储引擎是插件式的。

InnoDB引擎

3.1、存储结构

3.1.1、内存结构

• Buffer Pool

  缓冲池，简称BP。以页为单位，每个页的大小为16k。BP采用链表数据结构管理Page。

• Change Buffer

  写缓冲区，简称CB。
  占BP的25%，最大支持50%。
  仅适用于非唯一普通索引页。

• Log Buffer

  日志缓冲区，用来保存要存储到磁盘上的 Redo/Undo 日志数据。

• Adaptive Hash Index

  自适应哈希索引，用于优化BP的查询速度。
  InnoDB存储引擎会自动根据访问的频率和模式为某些页建立哈希索引。

3.1.2、磁盘结构

• System TableSpace

  系统表空间，包含：InnoDB数据字典、Double Writer Buffer、Change Buffer、Undo Logs 的存储区域。是一个共享表空间。

• File-Per-Table TableSpace

  独立表空间，是一个单表表空间，每个表空间由一个.ibd文件代表。表空间的表文件支持动态（dynamic）和压缩（compress）行格式。

• General TableSpaces

  通用表空间，创建于MySQL数据目录外的其他表空间。可以容纳多张表，支持所有行格式。

• Undo TableSpaces

  撤销表空间，由一个或多个包含Undo日志的文件组成。

• Temporary TableSpace

  临时表空间，分为 Session Temporary TableSpace 和 Global Temporary TableSpace。

• Redo Log

  重做日志，用在MySQL崩溃恢复期间，以更正不完整事务写入的数据。

3.2、数据文件

3.2.1、存储结构

• TableSpace

  表空间，用以管理多个ibd文件

• ibd

  .ibd文件，MySQL默认情况下的独立表空间模式的表文件，用于存储记录和索引。
  一个.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）等信息。

3.2.2、文件格式

• Antelope

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

  • REDUNDANT 行格式

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

  • COMPACT 行格式

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

• Barracuda

  新的文件格式。它支持InnoDB的所有行格式，包括：老的行格式REDUNDANT、COMPACT、和新的行格式COMPRESSED和 DYNAMIC。

  • DYNAMIC 行格式

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

  • COMPRESSED 行格式

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

3.3、线程模型

3.3.1、IO Thread

包含四个读线程（Read Thread）、四个写线程（Write Thread）、一个日志线程（Log Thread）、一个写缓冲线程（Insert Buffer Thread）。

读线程：负责读取操作，将数据从磁盘加载到Buffer Pool的Page中。
写线程：负责写操作，将缓存脏页刷新到磁盘。
日志线程：将日志缓冲区写入到磁盘。
写缓冲线程：负责将Change Buffer中的内容刷新到磁盘。

3.3.2、Purge Thread

默认有四个线程，用以清理已提交事务的 Undo Log 日志

3.3.3、Page Cleaner Thread

默认有一个线程，用以将Change Buffer 中的脏数据刷新至磁盘，脏数据刷盘后相应的redo log也就可以覆盖，既可以同步数据，又能达到redo log循环使用的目的。会调用write thread线程处理。

3.3.4、Master Thread

InnoDB中的主线程，优先级最高，负责调度其他线程。

作用：脏页的刷新（page cleaner thread）、undo页回收（purge thread）、redo日志刷新（log thread）、合并写缓冲等。

内部有两个定时任务，执行间隔非别是每隔1秒和每隔10秒。
每1秒的操作：
将日志缓冲区内容刷新至磁盘。
合并写缓冲区数据，根据IO读写压力来决定是否操作。
将脏页数据刷新至磁盘。（脏页比例达到75%才操作）
每10秒的操作：
刷新脏页数据到磁盘
合并写缓冲区数据
刷新日志缓冲区
删除无用的undo页

3.4、Undo Log

3.4.1、功能

数据库事务开始之前，会将要修改的记录存放到 Undo 日志里，当事务回滚时或者数据库崩溃时，可以利用 Undo 日志，撤销未提交事务对数据库产生的影响。

3.4.2、产生与销毁

Undo Log在事务开始前产生；事务在提交时，并不会立刻删除undo log，innodb会将该事务对应的undo log放入到删除列表中，后面会通过后台线程purge thread进行回收处理。Undo Log属于逻辑日志，记录一个变化过程。例如执行一个delete，undolog会记录一个insert；执行一个update，undolog会记录一个相反的update。

3.4.3、存储

undo log采用段的方式管理和记录。在innodb数据文件中包含一种rollback segment回滚段，内部包含1024个undo log segment。

3.4.4、作用

• 实现事务的原子性

  Undo Log 是为了实现事务的原子性而出现的产物。事务处理过程中，如果出现了错误或者用户执行了 ROLLBACK 语句，MySQL 可以利用 Undo Log 中的备份将数据恢复到事务开始之前的状态。

• 实现多版本并发控制（MVCC）

  Undo Log 在 MySQL InnoDB 存储引擎中用来实现多版本并发控制。事务未提交之前，Undo Log保存了未提交之前的版本数据，Undo Log 中的数据可作为数据旧版本快照供其他并发事务进行快
  照读。

3.5、Redo Log

3.5.1、功能

以恢复操作为目的，在数据库发生意外时重现操作。

3.5.2、产生与销毁

随着事务操作的执行，就会生成Redo Log，在事务提交时会将产生Redo Log写入Log Buffer，并不是随着事务的提交就立刻写入磁盘文件。等事务操作的脏页写入到磁盘之后，Redo Log 的使命也就完成了，Redo Log占用的空间就可以重用（被覆盖写入）。

3.5.3、存储

每个InnoDB存储引擎至少有1个重做日志文件组（group），每个文件组至少有2个重做日志文件，默认为ib_logfile0和ib_logfile1。

3.5.4、持久化策略

Redo Buffer 持久化到 Redo Log 的策略，可通过Innodb_flush_log_at_trx_commit 设置：
0：每秒提交 Redo buffer ->OS cache -> flush cache to disk，可能丢失一秒内的事务数据。由后台Master线程每隔 1秒执行一次操作。
1（默认值）：每次事务提交执行 Redo Buffer -> OS cache -> flush cache to disk，最安全，性能最差的方式。
2：每次事务提交执行 Redo Buffer -> OS cache，然后由后台Master线程再每隔1秒执行OS cache -> flush cache to disk 的操作。

一般建议选择取值2，因为 MySQL 挂了数据没有损失，整个服务器挂了才会损失1秒的事务提交数据。

四、系统文件层

4.1、日志文件

4.1.1、错误日志

默认开启
show variables like ‘%log_error%’

4.1.2、通用日志

记录一般查询语句
show variables like ‘%general%’

4.1.3、二进制日志

记录的MySQL的增删改操作，记录语句发生的操作时间、执行时长。
主要用于数据恢复和主从复制。

show variables like ‘%log_bin%’ // 是否开启
show variables like ‘%binlog%’ // 查看参数
show binary logs // 查看二进制文件

4.1.4、慢查询日志

记录查询时间超时的SQL，默认10秒。

show variables like ‘%slow_query%’ // 是否开启
show variables like ‘%long_query_time%’ // 超时时长

4.2、配置文件

存放MySQL的配置信息。如：my.ing my.cnf

4.3、数据文件

查看文件存放路径
show variables like ‘%datadir%’

• db.opt

  记录当前库使用的字符集和校验规则

• frm

  存储表相关的元信息，每张表对应一个 frm 文件

• MYD

  MyISAM引擎专用数据存储文件，每张表对应一个MYD文件

• MYI

  MySIAM 引擎专用索引存储文件，每张表都有一张对应的MYI文件

• ibd

  InnoDB引擎在独享表空间模式下的专用数据、索引存储文件。每张表都有其对应的ibd文件（常见，5.7 默认）

• ibdata

  InnoDB引擎在共享表空间模式下的专用数据、索引存储文件。每张表都有其对应的ibdata文件（少见）

• ib_logfile

  ib_logfile0、ib_logfile1：Redo log 日志文件

4.4、pid文件

Unix/Linux 环境的进程id文件，存放自己的进程id

4.5、socket文件

Unix/Linux 环境下客户端可以不通过 TCP/IP 连接MySQL，而直接使用 socket。

思维导图

下载（免费）

------------------------------------ 勇敢一点，限制你变强大的，可能是你的内心。 ------------------------------------