一、InnoDB体系结构概述
InnoDB的整体架构分为三部分：缓冲池(Buffer Pool)、后台线程、文件，如下图所示三部分
1.缓冲池
缓冲池是什么？
InnoDB存储引擎基于磁盘文件存储，访问物理硬盘和在内存中进行访问，速度相差很大，为了尽可能弥补这两者之间的I/O效率的差值，就需要把经常使用的数据加载到缓冲池中，避免每次访问都进行磁盘I/O。
在InnoDB的缓冲池中不仅缓存了索引页和数据页，还包含了undo页、插入缓存、自适应哈希索引以及InnoDB的锁信息等等。
读取数据工作流程
在数据库中进行读取页的操作时， 首先将磁盘中读取到的页数据存放在缓冲池中， 下一次再读相同的页时， 首先判断缓冲池中是否存在，如果缓冲池被命中，则直接读取数据， 如果没有，则读取磁盘中的页数据。
更新数据工作流程
对于数据库中页的修改操作，则首先修改在缓冲池中的页，然后再以一定的频率刷新到磁盘上，从而保证缓冲池中的数据与磁盘中的数据一致。页从缓冲池刷新回磁盘的操作并不是在每次页发生更新时，都需要触发，出于整体的性能考虑，而是通过checkpoint机制刷新回磁盘。
如何配置缓冲池
show variables like 'innodb_buffer_pool_size';
修改这个变量的值即可修改缓冲池的大小
2.后台线程
我们将分别对InnoDB中的四个后台线程做介绍
Master Thread（主线程，可以调用下面三个线程）
主要负责将缓冲池中的数据异步刷新到磁盘中, 保持数据的一致性， 还包括脏页的刷新、合并插入缓存、undo页的回收 。
IO Thread
在InnoDB存储引擎中大量使用了AIO来处理IO请求, 这样可以极大地提高数据库的性能，而IO
Thread主要负责这些IO请求的回调。
Purge Thread
主要用于回收事务已经提交了的undo log，在事务提交之后，undo log可能不用了，就用它来回
收。
Pager Cleaner Thread
新引入的一个用于协助 Master Thread 刷新脏页到磁盘的线程，它可以减轻 Master Thread 的
工作压力，减少阻塞。
3.文件
InnoDB中的各类文件就是真正落盘后的文件，记录了整个MySQL存储所需的所有内容。当然，这些文件肯定也分门别类，下面一一介绍
frm文件
该文件是用来保存每个表的元数据信息的， 主要包含表结构定义 。
系统表空间
系统表空间是InnoDB数据字典，二次写缓冲区，更改缓冲区和Undo Log的存储区 。
系统表空间可以具有一个或多个数据文件， 默认情况下会在数据存放目录中创建一个名为 ibdata1 表空间数据文件。该文件名称可以通过参数 innodb_data_file_path 指定。
独占表空间
innodb中设置了参数 innodb_file_per_table 为 1/ON，则会将存储的数据、索引等信息单独存储在一个独占表空间，因此也会产生一个独占表空间文件（ibd）
redo log
重做日志， 用于恢复提交事务修改的页操作 ， 用来保证事务的原子性和持久性。
主要是解决 提交的事务没有执行完成但是数据库崩溃了，当数据库恢复之后，可以完整的恢复数据。在执行操作时，InnoDB存储引擎会首先将重做日志信息放到这个缓冲区 redo log buffer,然后按照不同的策略和频率将buffer中的数据刷新到重做日志中。
redo log在磁盘中保存的名称为 ib_logfile0，ib_logfile1。
bin log
二进制日志，其中记录表结构中的数据变更，包含DDL与DML。
其他
错误日志、查询日志、慢查询日志等。
二、InnoDB逻辑存储结构
InnoDB的逻辑存储数据结构就是以下图所示
表空间(TableSpace)
表空间是InnoDB存储引擎逻辑结构的最高层， 大部分数据都存在于共享表空间ibdata1中。如果用
户启用了参数 innodb_file_per_table ，则每张表都会有一个表空间（xxx.ibd）,里面存放表中的数据、索引和插入缓存Bitmap页。其他的数据如undo log、插入缓存索引页、系统事务信息、二次写缓存都是在共享表空间中。
段(Segment)
表空间是由各个段组成的， 常见的段有数据段、索引段、回滚段等。InnoDB存储引擎是基于索引组织的，因此数据即是索引，索引即数据。数据段就是B+树的叶子节点， 索引段即为B+树的非叶子节点。
InnoDB中对于段的管理，都是引擎自身完成，不需要人为对其控制。
区(Extent)
区是表空间的单元结构，每个区的大小为1M。 默认情况下， InnoDB存储引擎页大小为16K， 即一个区中一共有64个连续的页。
页(Page)
页是组成区的最小单元，页也是InnoDB 存储引擎磁盘管理的最小单元，每个页的大小默认为16KB。为了保证页的连续性，InnoDB 存储引擎每次从磁盘申请 4-5 个区。
行(row)
InnoDB 存储引擎是面向行的（row-oriented)，也就是说数据是按行进行存放的，每个页存放的行
记录也是有硬性定义的，最多允许存放 16KB/2-200 行，即 7992 行记录。
- trx_id：每次对某条聚簇索引记录进行改动时，都会把对应的事务id赋值给trx_id隐藏列。
- roll_pointer：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到undo日志中，然后这个隐藏列 就相当于一个指针，可以通过它来找到该记录修改前的信息。
三、checkpoint机制
checkpoint介绍
由于日常的DML语句操作时，首先操作的是缓冲池，并没有直接写入到磁盘，这有可能会导致内存中的数据与磁盘中的数据产生不一致的情况，而与磁盘中数据不一致的页我们成为"脏页"。
而checkpoint的工作，就是将内存中的脏页，在一定条件下刷新到磁盘。
如果在从缓冲池将页数据刷新到磁盘的过程中发生宕机，那么数据就无法恢复了；为了避免这种情况的发生，采用了Write Ahead Log(WAL)策略，即当事务提交时，先写重做日志(redo log)，再修改缓冲池数据页，最后通过Checkpoint刷新到磁盘（事务提交会触发checkpoint）。这样正在执行的事务，因为存在日志都可以被恢复，没有日志的事务还没有执行也不会丢失数据。
checkpoint有什么作用
（1）缩短数据恢复时间
当数据库发生宕机时，数据库不用重做所有的日志，因为Checkpoint之前的页都已经刷新到磁盘了，故数据库只需要重做Checkpoint之后的日志就好，这样就大大缩短了恢复时间。
（2） 缓冲池不够用时，需要先将脏页数据刷新到磁盘中；
当缓冲池不够用时, 根据LRU算法溢出最近最少使用的页, 如果此页是脏页,则强制执行Checkpoint, 刷新脏页到磁盘。
（3）Redo log不可用时，刷新脏页到磁盘；
redo log大小是固定的, 当前的InnoDB引擎中， 重做日志的设计都是循环使用的，并不是无限增
大的。重做日志可以被重用的部分是已经不再需要的， 数据库发生宕机也不需要这部分的重做日志，因此可以被覆盖使用， 如果此时重做日志还需要使用，那么必须强制执行Checkpoint，将缓冲池中的页至少刷新磁盘, checkpoint移动到当前重做日志的位置。
如上图所示，write position到checkpoint的中间区域才是redo log可写入的区域。当这部分区域用完了，如中间的那副图，这就发生了redo log不可用，这时要强制通过checkpoint刷新页到磁盘
两类checkpoint
- Sharp Checkpoint：Sharp Checkpoint 发生在数据库关闭时，将所有的脏页都刷新回磁盘，这是默认的工作方式，参数：innodb_fast_shutdown=1。
- Fuzzy Checkpoint：在InnoDB存储引擎运行时，使用Fuzzy Checkpoint进行页刷新，只刷新一部分脏页。