【MySQL】一文带你理清InnoDB引擎的＜内部架构＞（内存结构，磁盘结构，后台线程）

本文主要是介绍【MySQL】一文带你理清InnoDB引擎的＜内部架构＞（内存结构，磁盘结构，后台线程），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言

大家好吖，欢迎来到 YY 滴MySQL系列 ，热烈欢迎！ 本章主要内容面向接触过C++ Linux的老铁
主要内容含：

欢迎订阅 YY滴C++专栏！更多干货持续更新！以下是传送门！

• YY的《C++》专栏
• YY的《C++11》专栏
• YY的《Linux》专栏
• YY的《数据结构》专栏
• YY的《C语言基础》专栏
• YY的《初学者易错点》专栏
• YY的《小小知识点》专栏
• YY的《单片机期末速过》专栏
• YY的《C++期末速过》专栏
• YY的《单片机》专栏
• YY的《STM32》专栏
• YY的《数据库》专栏
• YY的《数据库原理》专栏

一.架构

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

1.内存结构

InnoDB引擎的内存架构分为下面四个：

1. 缓冲池：Buffer Pool
2. 更改缓冲区：Change Buffer——（针对非唯一，二级索引页）
3. 自适应哈希索引
4. 日志缓冲区

1.缓冲池：Buffer Pool

2.更改缓冲区：Change Buffer

• Change Buffer的意义
• 在增删改查时，不用每一次直接操作磁盘IO， 先操作Change Buffer中的数据（合并处理等操作）。
• 再以一定频率把Change Buffer中的数据同步到Buffer Pool ，最后再刷新到磁盘中
  
  

3.自适应哈希索引：Adaptive Hash index

• InnoDB引擎 默认不支持哈希索引 ，支持 B+树索引。
• 前情提要，哈希索引优势是快，只需要一次匹配即可(排除哈希冲突情况下)。而B+树则需要匹配两三次。
• 但哈希索引的局限在于，不能做范围查询，只能做等值匹配等操作
• 所以自适应哈希索引等于是上了一层自动监控， 如果hash索引更快，他会建立哈希索引
  

4.日志缓冲区：Log Buffer

• 用于保存日志文件redolog，undolog
  

2.磁盘结构

结构总览，具体解读在下面

1.系统表空间：System Tablespace

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

2.表的独立表空间：File-Per-Table Tablespaces

• 取决于独立表空间的开关【参数:innodb_file_per_able】是否开启，若开启。则相关数据不会上上文所述系统表空间System Tablespace中存放
• File-Per-Table Tablespaces:每个表的文件表空间包含单个InnoDB表的数据和索引，并存储在文件系统上的单个数据文件中
  

3.通用表空间：GeneralTablespaces

• 不自己创建，则没有这块表空间文件
• GeneralTablespaces:通用表空间，需要通过CREATE TABLESPACE 语法创建通用表空间，在创建表时，可以指定该表空间。
  

4.撤销表空间：Undo Tablespaces

• Undo Tablespaces:撤销表空间，MySQL实例在初始化时会自动创建 两个默认的undo表空间 (初始大小16M)(图中undo_001,undo_002)，用于存储undolog日志。
  

5.临时表空间：Temporary Tablespaces

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

6.双写缓冲区：Doublewrite Buffer Files

• 一个中转的缓冲区， 出意外时可以通过双写缓冲区恢复数据
• Doublewrite Buffer Files:双写缓冲区，innoDB引擎将数据页从Buffer Pool刷新到磁盘前，先将数据页写入双写缓冲区文件中，便于系统异常时恢复数据。
• 双写缓冲区文件【.dblwr】
  

7.重做日志：Redo Log

• Redo Log:重做日志，是用来实现事务的持久性。不会一直保存，隔一段时间会清理没有使用的Redo Log
• 该日志文件由两部分组成: 重做日志缓冲 (redo logbuffer)以及 重做日志文件 (redo log),前者是在内存中，后者在磁盘中。
• 当事务提交之后会把 所有修改信息 都会存到该日志中,用于在刷新脏页到磁盘时,发生错误时,进行数据恢复使用。
• 循环写入涉及下面两个文件
  
  

3.后台线程——把缓冲池信息刷新到磁盘当中

• 后台线程主要作用：把缓冲池信息在合适的时机刷新到磁盘当中
  

• 分为4个线程

1. Master Thread
   核心后台线程，负责调度其他线程，还负责将缓冲池中的数据异步刷新到磁盘中,保持数据的一致性还包括脏页的刷新、合并插入缓存、undo页的回收
2. IO Thread
   在InnoDB存储引擎中大量使用了AIO来处理IO请求,这样可以极大地提高数据库的性能，而I0Thread主要负责这些IO请求的回调。
   
3. Purge Thread
   主要用于回收事务已经提交了的undolog，在事务提交之后，undolog可能不用了，就用它来回收。
4. Page Cleaner Thread
   协助 Master Thread 刷新脏页到磁盘的线程，它可以减轻 Master Thread 的工作压力，减少阻塞。

这篇关于【MySQL】一文带你理清InnoDB引擎的＜内部架构＞（内存结构，磁盘结构，后台线程）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---