MySQL技术内幕：MySQL—InnoDB存储引擎体系架构——详解

InnoDB存储引擎体系架构

本篇主要介绍InnoDB存储引擎的体系架构，之后的几篇博客会详细介绍InnoDB的几大特征以及具体实现！喜欢的朋友可以关注一下！

1.存储引擎

1.1概念

• 首先明确一个概念，存储引擎是基于表的，不是基于数据库的
• 其次存储引擎指的是表的底层物理结构的实现，也就是表在底层是如何存储的，不同的存储引擎存储表的物理结构不同
• MySQL数据库最大的特点就是插件式的表存储引擎，即支持多种存储引擎，目前默认的存储引擎是InnoDB，但是其还支持：MyISAM，NDB，Memory，Archive，Federated，Maria等存储引擎，不同的存储引擎有着自己管理表和存储表的方式
• 下图为Mysql数据库的体系结构图，可以看到底层第二层为多种存储引擎支持：
  

2.InnoDB体系架构

2.1InnoDB架构图

• InnoDB存储引擎有多个内存块，可以认为这个内存块组成了一个大的内存池，内存池的作用主要有以下几点：
  1）维护所有进程/线程需要访问的多个内部数据结构
  2）缓存磁盘上的数据，方便快速读取，同时在对磁盘文件的数据修改之前也会在这里缓存
  3）重做日志（redo log）缓冲
• InnoDB存储引擎中还包括多个后台线程，这些后台线程的作用主要是刷新内存池中的数据，保证内存缓存的是最近的数据。此外还要将数据文件刷新到磁盘文件，保证数据库发生异常时可以恢复状态。

2.2 后台线程

• InnoDB存储引擎是多线程的模型，有多个后台线程去负责处理不同的任务

2.2.1 Master Thread

• 该线程是一个非常核心的后台线程，主要负责将缓冲池中的数据异步刷新到磁盘中，保证数据的一致性。包括脏页的刷新，合并插入缓冲，UNDO页回收等

• 脏页：由于InnoDB在进行表数据修改的时候，并不是直接修改磁盘上的数据文件，而是将磁盘上的页缓存到缓冲池中进行修改，之后再根据一定的机制和频率刷新回磁盘，这种还没有刷新回磁盘但是已经被修改的页称为脏页。

• 合并插入缓冲：当要插入非聚集索引的时候，将其放在缓冲内存中保存，根据一定的机制和频率将要插入的非聚集索引一起刷新到索引页中。
  对与聚集索引和非聚集索引的底层不理解的可以看这篇博客：聚集索引，非聚集索引的底层实现——详解

• 插入缓冲是InnoDB的几大特性之一，后面会专门写几篇博客详细介绍这几大特性（插入缓冲，两次写，自适应哈希索引，异步IO，刷新邻接页）
  插入缓冲的原理讲解已经更新：InnoDB存储引擎特性之插入缓冲——详解
  两次写的原理讲解已更新：InnoDB存储引擎特性之两次写——详解
  自适应哈希索引讲解已更新： InnoDB存储引擎关键特性之自适应哈希索引——详解

• 对于Master Thread线程的具体工作方式，在后面也会有单独的文章详解

  Master Thread底层原理已更新：InnoDB存储引擎之Master Thread详解

2.2.2 IO Thread

• 在InnoDB存储引擎中使用了大量的AIO（Async IO）来处理写IO请求，这样可以极大的提高数据库的性能，而IO Thread的工作主要是负责这些IO请求的回调处理
• Async IO：这种IO方式的优点在于可以进行IO Merge操作，也就是将多个IO合并为一个IO。并且用户可以在发送出一个IO请求之后，继续发送IO请求，当全部IO请求发送完毕后，再等待所有的IO操作的完成。
• 举例：例如用户有三个请求需要访问三个相邻页，也就是连续发送三个IO请求，那么此时同步IO就需要进行三次IO操作，但是AIO会判断这三个页是连续的，因此会一次性将三个页全部读取出来！
• 在InnoDB 1.0版本之前一共有一个IO Thread，分别是write Thread， read Thread，insert buffer Thread，log IO Thread.
• 从1.0.x版本之后开始，write Thread， read Thread的数量分别增大到了四个

2.2.3 Purge Thread

• Purge Thread主要的作用是回收已经使用并分配的undo页
• undo日志：用于存放数据修改被修改前的值，假设修改表中 id=2的行数据，把Name=‘B’ 修改为Name = ‘B2’ ，那么undo日志就会用来存放Name='B’的记录，如果这个修改出现异常，可以使用undo日志来实现回滚操作，保证事务的一致性。
• 对数据的变更操作，主要来自 INSERT UPDATE DELETE，而UNDO LOG中分为两种类型，一种是 INSERT_UNDO（INSERT操作），记录插入的唯一键值；一种是 UPDATE_UNDO（包含UPDATE及DELETE操作），记录修改的唯一键值以及old column记录

2.2.4 Page Cleaner Thread

• 作用就是刷新脏页，这个线程是1.2.x版本中引入的，将刷新脏页的操作放入单独的线程中完成，减轻原Master Thread的工作量，提高存储引擎的性能

2.3 内存

2.3.1 内存池组成

• 缓冲池
• （重做）日志缓冲
• 额外内存池

2.3.2 缓冲池

• InnoDB存储引擎是基于磁盘存储的，但是每次和磁盘进行IO的速度不如与内存IO的速度，所以引入的缓冲池，用缓冲池技术来提高数据库的整体性能
• 缓冲池简单来说就是一块内存区域，在数据库中读取页的操作，首先将磁盘中的页读取到缓冲池中，再进行读取。下一次读取的时候如果该页还在缓冲池中，就不需要和磁盘进行IO了
• 对于数据库中修改页的操作，也是先在缓冲池中进行修改，然后根据一定的机制和频率刷新回磁盘中。这种机制称为CheckPoint
• 缓冲池中不仅仅是缓存索引页和数据页，这的确是占了大部分内存，但是实际上还有插入缓冲，锁信息，自适应哈希索引，数据字典信息
• 缓冲池的工作原理请关注后续文章！

2.3.3 重做日志缓冲

• 可以看到重做日志缓冲也是内存池的一部分，InnoDB存储引擎首先将重做日志信息先放到这个缓冲区，然后按一定的频率刷新到重做日志文件
• 重做日志文件：其实就是一种记录操作的日志，为了可以回滚
• 有下列三种情况会将重做日志缓冲中的内容刷新到磁盘的重做日志文件中：
  1）Master Thread每一秒会将重做日志缓冲刷新到日志文件
  2）每个事务提交时会进行刷新
  3）当重做日志缓冲池剩余控件小于2/1时，也会进行刷新

2.3.4 额外的内存池

• 这个额外的内存池的主要作用就是当其他内存池中需要分配额外的内存时，要从这个内存池中申请内存。

3.总结

• 以上就是InnoDB存储引擎体系架构的各部分组成以及作用，但是每一部分都有一定的工作原理，后续我会继续更新！请关注！