Mysql进阶- InnoDB引擎架构

ゝ一世哀愁。 2024-02-05 12:18 16阅读 0赞

## 逻辑存储结构 ##

InnoDB的逻辑存储结构如下图所示:

![8bab04fb05e44149bc379a3b215d82fc.png][]

> 1). **表空间**是InnoDB存储引擎逻辑结构的最高层， 如果用户启用了参数 innodb\_file\_per\_table(在 8.0版本中默认开启) ，则每张表都会有一个表空间（xxx.ibd），一个mysql实例可以对应多个表空间，**用于存储记录、索引等数据**。
> 
> 2). **段**，分为数据段（Leaf node segment）、索引段（Non-leaf node segment）、回滚段 （Rollback segment），InnoDB是索引组织表，数据段就是B+树的叶子节点， 索引段即为B+树的 非叶子节点。**段用来管理多个Extent（区）**。
> 
> 3). **区**，表空间的单元结构，每个区的大小为1M。 默认情况下， InnoDB存储引擎页大小为16K， **即一个区中一共有64个连续的页**。
> 
> 4).  **页**，是InnoDB 存储引擎磁盘管理的最小单元，每个页的大小默认为 16KB。**为了保证页的连续性， InnoDB 存储引擎每次从磁盘申请 4-5 个区**。
> 
> 5). **行**，InnoDB 存储引擎数据是按行进行存放的。

在行中，默认有两个隐藏字段：

> Trx\_id：每次对某条记录进行改动时，都**会把对应的事务id赋值给trx\_id隐藏列**。 Roll\_pointer：每次对某条引记录进行改动时，都会把旧的版本写入到undo日志中，然后这个 隐藏列就相当于一个指针，**可以通过它来找到该记录修改前的信息**。

## 架构概述 ##

MySQL5.5 版本开始，默认使用InnoDB存储引擎，它擅长事务处理，具有崩溃恢复特性，在日常开发 中使用非常广泛。下面是InnoDB架构图，左侧为内存结构，右侧为磁盘结构。

![21b4607bb381467496ceb84a06a4208c.png][]

## 内存结构 ##

在左侧的内存结构中，主要分为这么四大块儿： Buffer Pool、Change Buffer、Adaptive Hash Index、Log Buffer。 接下来介绍一下这四个部分。

![ce8a2a4ded7a4daf85d52853ef18db7f.png][]

### Buffer Pool 缓冲池 ###

InnoDB存储引擎基于磁盘文件存储，访问物理硬盘和在内存中进行访问，速度相差很大，为了尽可能弥补这两者之间的I/O效率的差值，就需要把经常使用的数据加载到缓冲池中，避免每次访问都进行磁 盘I/O。 在InnoDB的缓冲池中不仅**缓存了索引页和数据页**，还**包含了undo页、插入缓存、自适应哈希索引以及 InnoDB的锁信息**等等。

缓冲池以Page页为单位，底层采用链表数据结构管理Page。根据状态，将Page分为三种类型：

>  *  free page：空闲page，未被使用。
>  *  clean page：被使用page，数据没有被修改过。
>  *  dirty page：脏页，被使用page，数据被修改过，也中数据与磁盘的数据产生了不一致。

在专用服务器上，通常将多达80％的物理内存分配给缓冲池，参数查看show variables like 'innodb\_buffer\_pool\_size';

![76579f7e1cf64a0686097e84695c1a11.png][]

### Change Buffer 更改缓冲区 ###

> Change Buffer，更改缓冲区（**针对于非唯一二级索引页**），在执行DML语句时，如果这些数据Page 没有在Buffer Pool中，不会直接操作磁盘，而会将数据变更存在更改缓冲区 Change Buffer 中，在未来数据被读取时，再将数据合并恢复到Buffer Pool中，再将合并后的数据刷新到磁盘中。**即数据在BufferPoo 中不存在，不专门为修改去进行10提作，而是等待下次查询这个数据时顺便去发起IO操作改数据，呈现崭新的数据给用户，有用于合并IO请求，减少磁盘IO**

### Adaptive Hash Index 自适应哈希索引 ###

自适应哈希索引，无需人工干预，是系**统根据情况自动完成**，跟查询时走不走索引类似的，都是由系统自动完成

> 自适应hash索引，用于优化对Buffer Pool数据的查询。MySQL的innoDB引擎中虽然没有直接支持hash索引，但是给我们提供了一个功能就是这个自适应hash索引。因为前面我们讲到过，hash索引在进行等值匹配时，一般性能是要高于B+树的，因为hash索引一般只需要一次IO即可，而B+树，可能需要几次匹配，所以hash索引的效率要高，但是hash索引又不适合做范围查询、模糊匹配等。 **InnoDB存储引擎会监控对表上各索引页的查询，如果观察到在特定的条件下hash索引可以提升速度， 则建立hash索引，称之为自适应hash索引**。

### Log Buffer 日志缓冲区 ###

Log Buffer：日志缓冲区，用来保存要写入到磁盘中的log日志数据（redo log 、undo log）， 默认大小为 16MB，日志缓冲区的日志会定期刷新到磁盘中。如果需要更新、插入或删除许多行的事 务，增加日志缓冲区的大小可以节省磁盘 I/O。

参数:

> innodb\_log\_buffer\_size：缓冲区大小
> 
> innodb\_flush\_log\_at\_trx\_commit：日志刷新到磁盘时机，取值主要包含以下三个：
> 
> 1: 日志在每次事务提交时写入并刷新到磁盘，默认值。
> 
> 0: 每秒将日志写入并刷新到磁盘一次。
> 
> 2: 日志在每次事务提交后写入，并每秒刷新到磁盘一次。

## 磁盘结构 ##

![e63f7090e0b641a4bbb4866df4a58544.png][]

### System Tablespace 系统表空间 ###

> 系统表空间是更改缓冲区的存储区域。如果表是在系统表空间而不是每个表文件或通用表空间中创建的，它也可能包含表和索引数据。(在MySQL5.x版本中还包含InnoDB数据字典、undolog等)

查看系统表空间的参数：innodb\_data\_file\_path，系统表空间，默认的文件名叫 ibdata1。

![6d07c1882b1c4b7a92dd1de2330d130d.png][]

### File-Per-Table Tablespaces 文件表空间 ###

> 如果开启了innodb\_file\_per\_table开关 ，则每个表的文件表空间包含单个InnoDB表的数据和索 引 ，并存储在文件系统上的单个数据文件中。

开关参数：innodb\_file\_per\_table ，该参数默认开启。

![1f38108f24df4d7a99836d4e732e583a.png][]

那也就是说，我们每创建一个表，都会产生一个表空间文件，如图：

![58979a48ea08496a93e1e11a4b845ef2.png][]

### General Tablespaces 通用表空间 ###

> 通用表空间，需要通过 CREATE TABLESPACE 语法创建通用表空间，在创建表时，可以指定该表空间。

创建表空间

CREATE TABLESPACE ts_name ADD DATAFILE 'file_name' ENGINE = engine_name;

![86a7f1ab1aac46bfb1edf7f48efe3005.png][] 创建表时指定表空间

> CREATE TABLE xxx ... TABLESPACE ts\_name;

### ![b22f0ce56c6d430cb1a3aca0864b0c16.png][] Undo Tablespaces 撤销表空间 ###

> 撤销表空间，MySQL实例在初始化时会自动创建两个默认的undo表空间（初始大小16M），用于存储undo log日志。

### Temporary Tablespaces 临时表空间 ###

> InnoDB 使用会话临时表空间和全局临时表空间。存储用户创建的临时表等数据。

### Doublewrite Buffer Files 双写缓冲区 ###

> 双写缓冲区，innoDB引擎将数据页从Buffer Pool刷新到磁盘前，先将数据页写入双写缓冲区文件 中，便于系统异常时恢复数据。

![d98247aa472349509af04a5c784a8ffa.png][]

### Redo Log 重做日志 ###

> 重做日志，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log）,前者是在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都会存到该日志中, 用于在刷新脏页到磁盘时,发生错误时, 进行数据恢复使用。

以循环方式写入重做日志文件，涉及两个文件：

![9f6266c1d1a7489caace8b21951a81f1.png][]

## 后台线程 ##

内存中我们所更新的数据，由后台线程负责在合适的时候刷新到磁盘，在InnoDB的后台线程中，分为4类，分别是：Master Thread 、IO Thread、Purge Thread、 Page Cleaner Thread。

![0ca9eb5cbfed402280bbaa973eaf0400.png][]

### Master Thread ###

> 核心后台线程，负责调度其他线程，还负责将缓冲池中的数据异步刷新到磁盘中, 保持数据的一致性， 还包括脏页的刷新、合并插入缓存、undo页的回收 。

### IO Thread ###

> 在InnoDB存储引擎中大量使用了AIO(**异步非阻塞IO，效率高**)来处理IO请求, 这样可以极大地提高数据库的性能，而IO Thread主要负责这些IO请求的回调。

![56e71e828cee4819b79ba96b94ca0287.png][]

### Purge Thread ###

> 主要用于回收事务已经提交了的undo log，在事务提交之后，undo log可能不用了，就用它来回 收。

### Page Cleaner Thread ###

> 协助 Master Thread 刷新脏页到磁盘的线程，它可以减轻 Master Thread 的工作压力，减少阻 塞。

[8bab04fb05e44149bc379a3b215d82fc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/69320fc31bb749b1a8736e21c79c64e6.png
[21b4607bb381467496ceb84a06a4208c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/5471948fe6a74051b3ee542319ff7ffd.png
[ce8a2a4ded7a4daf85d52853ef18db7f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/9603a136be6c48c3a18373ebffb3a7b1.png
[76579f7e1cf64a0686097e84695c1a11.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/f74d385f80964072b34346b51ce18594.png
[e63f7090e0b641a4bbb4866df4a58544.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/3e4060bba8d84c679c16cdd0cee0b0da.png
[6d07c1882b1c4b7a92dd1de2330d130d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/bf61be39487d44a1b64e9ca0d283b13a.png
[1f38108f24df4d7a99836d4e732e583a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/44b513d7f9ae47f9bcffe95a2e570800.png
[58979a48ea08496a93e1e11a4b845ef2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/f208f7e8e96544de88a0d7a1d0031d71.png
[86a7f1ab1aac46bfb1edf7f48efe3005.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/e2400a3b427543e2aacab3429b66945b.png
[b22f0ce56c6d430cb1a3aca0864b0c16.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/fe9d041f37704e98826a69f9196ceddd.png
[d98247aa472349509af04a5c784a8ffa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/b0bb08633040427c99088a8b80d08dad.png
[9f6266c1d1a7489caace8b21951a81f1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/cd73cecac540474fbde85c16c75a74e0.png
[0ca9eb5cbfed402280bbaa973eaf0400.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/5530bdf9346147048ea63ec83797cbbc.png
[56e71e828cee4819b79ba96b94ca0287.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/3744de8657304edcba78feee11b5aea6.png