一、MySQL后台线程
1、Master Thread
核心后台线程，主要负责将缓冲池的数据异步刷新到磁盘。例如脏页的刷新，插入缓冲的合并，undo 页的回收等。
1）每秒一次的操作：日志缓冲刷新到磁盘，即使该事务还没有提交。该操作总是会发生，这个就是为了再大的事务，提交时间都很短。
当IO压力很小时（1s内发生的IO次数小于5% innodb_io_capacity）合并5% innodb_io_capacity 的插入缓冲。
当脏页比例大于 innodb_max_dirty_pages_cnt, 刷新 innodb_io_capacity 个缓冲池中的脏页到磁盘。否则如果 innodb_adaptive_flush 开启，则根据buf_flush_get_desired_flush_rate 来选择合适刷新脏页数量进行刷新。2）每10秒一次的操作：
如果过去10S 内IO操作小于 innodb_io_capacity， 刷新 innodb_io_capacity 个缓冲池中的脏页到磁盘。
合并5% innodb_io_capacity 个插入缓冲。
将日志缓冲刷新到磁盘。
删除无用的undo页。
如果缓冲池中脏页比例超过70%，再次刷新 innodb_io_capacity 个脏页到磁盘。否则刷新10% innodb_io_capacity 个脏页。
3）background loop(数据库空闲或者数据库关闭时):
删除无用的undo页。
合并 innodb_io_capacity 个插入缓冲。
4）flush loop(数据库空闲）：
刷新 innodb_io_capacity 个脏页
2、IO Thread
Innodb存储引擎大量使用了AIO， IO Thread主要负责IO请求的回调。 可使用innodb_read_io_threads和innodb_write_io_threads参数列表调 整。3、Purge Thread
事务提交后。该事务相关的undolog可能不再需要。Purge Thread就是用来回收不需要的undo页的。
4、PageCleaner Thread
负责脏页的刷新操作。减轻master thread的工作以及对于用户查询线程的阻塞。
二、 内存缓冲池
对于数据库中页的修改操作，首先修改在缓冲池中的页，然后再以一定的频率刷新到磁盘上。这就意味着不是每次缓冲池中的页修改时触发刷新回磁盘，而是通过checkpoint技术刷新回磁盘。缓冲池的大小配置可通过 innodb_buffer_pool_size来设置。缓冲池的数据页类型有：数据页，索引页，undo页，插入缓冲，自适应哈希索引，innodb存储的锁信息，字典信息。
现在innodb存储引擎允许多个缓冲池实例。这样通过hash到不同缓冲池实例来减少锁的竞争。该参数可以通过 innodb_buffer_pool_instance.
缓冲池是一个很大的内存区域，数据库通过LRU算法来进行管理。但是因为考虑到全表扫描的操作。因此没有采用朴素的LRU算法。LRU列表中加入的midpoint位置。新读取到的页，并不是直接放到LRU列表的首部，而是midpoint位置。默认情况下，在LRU列表长度的5/8处。由参数innodb_old_blocks_pct控制。
1、插入缓冲
对于非聚集索引的插入和更新操作，Innodb存储引擎并不是直接插入到索引页中，而是的Insert Buffer。然后再以一定的频率进行insertbuffer和辅助索引叶子节点的merge。通常将多个随机插入合并到一个操作中。大大提高了非聚集索引插入的性能。
Innodb使用 insertbuffer 条件：A、索引是非聚集索引；B、索引不是unique的(如果是unique, 则又需查找索引来保证unique)
Insert Buffer 内部实现
Insert Buffer 的数据结构是一棵B+树。 Mysql 4.1后，全局只有一棵B+树，负责对所有表的辅助索引进行insert Buffer. 并且，这棵树存放在共享 表空间里，默认情况下即ibdata1。因此，如果仅通过独立表空间ibd文件恢复表中数据时，可能会导致失败。还需要通过insert buffer数据恢复表上的 辅助索引。
Insert Buffer 的非叶节点存放的是查询key, 构造如 space(4字节） + marker（1字节） + offset（4字节）。space表示记录所在表的表空间ID， offset表示页的偏移量。marker用来兼容老版本。
Insert Buffer 叶子几点构造如 space + marker + offset + metadata + records。 space, marker, offset和前述意义相同。 metadata里的 IBUF_REC_OFFSET_COUNT保存了两个字节的整数，用来排序记录进入 Insert Buffer 的顺序。通过这个顺序回访呢个得到记录的正确值。从 Insert Buffer 叶子节点的第5列开始，才是实际插入的各个记录。
启用 Insert Buffer索引后，辅助索引页的记录可能被插入到 Insert Buffer B+树中。为了保证每次合并插入缓冲区成功， 必须要有一块地方能标记每 个辅助索引页的可用空间。 Insert Buffer采用一个特殊的页来标记，该页的类型为 Insert Buffer Bitmap。每个 Insert Buffer Bitmap页用来追踪 16384个页，也就是256个区。每个Insert Buffer Bitmap 页都在16384个页的第二个页。每个辅助索引页在Bit map中占用4个字节，这里面主要用 于表示辅助索引页的可用数量。
合并插入缓冲
Insert Buffer中的记录在以下情况下合并到真正的辅助索引中：
1)辅助索引页被读到缓冲池中；2)Insert Buffer Bitmap 页追踪到该辅助索引页已无可用空间时；
3)Master Thread调度时；
这样子，对辅助索引页的多次记录操作通过一次操作合并到了原有的辅助索引页中，从而提高性能。
两次写（Double Write)
InsertBuffer 给 Innodb 存储引擎带来了性能的提升，而两次写带给 Innodb 存储引擎的是数据页的可靠性。
可能会有疑问，如果发生写失败，那么不是可以通过重做日志进行恢复的吗？这的确是一个办法，但是必须知道，重做日志记录的是页的物理操作，如偏移量 800， 写‘aaa‘记录。但是，如果这个页已经损坏了，对其进行重做是没有意义的。这意味着，在修改页前，必须有一个正确的页的副本存在，当写入失效发生 时，先通过页的副本还原该页，再进行重做，这就是double write。
Double write由两部分组成，
一部分是内存中的 double write buffer；另一部分是在物理磁盘上的共享表空间中的连续128个页，大小和内存中（2M）一致。
对缓冲池中的页进行刷新时，并不直接写磁盘，而是memcpy到double write buffer. 之后通过 double write buffer 分两次，每次顺序写入共享 表空间1M数据，然后马上调用fsync同步磁盘。这个写入因为共享表空间的double write页是连续的，因此开销不是很大。而完成 double write 页的 写入后，再将double write buffer中的页写入各个表空间则是离散的写入。
如果操作系统在将页写入磁盘的过程中发生了崩溃。那么恢复时则可以从共享表空间中double write buffer页找到该页的副本。将其复制到表空间再应 用重做日志。2、自适应HASH索引
Innodb 存储引擎会监控对表上各索引页的查询，如果观察到建立hash索引可以带来速度的提升,则建立hash索引，称之为自适应hash索引(AHI).
AHI有一个要求，即对这个页的连续访问模式必须是一样的. 例如（a, b)这样的联合索引，启访问模式可以使：
WHERE a = xxx
WHERE a = xxx and b = yyy
访问模式一样就是说查询的条件一样,如果交替执行上述的查询操作则不会建立AHI。
另外，AHI还要求以同一个模式访问了100次，页通过该模式访问了N次，其中N = 页中记录 * 1/16
刷新邻近页
当刷新一个脏页时，Innodb存储引擎会通过检测该页所在区的所有页，如果是脏页，会一起进行刷新。
异步IO
Innodb 采用异步IO的方式来处理磁盘操作。
Check Point技术
为了避免数据丢失的问题，事物数据库系统一般都采用了write ahead log策略;即事物提交时，先写重做日志，再修改页。
但是重做日志不可能无限增大，缓冲值（未刷新到磁盘的脏页）也不可能无限大;即便真可以无限大，数据库宕机后恢复时间也会很长;所以就需要 Check Point技术，该技术可以解决：
缩短数据库恢复的时间；
缓冲池不够用时，可以将脏页刷新到磁盘；
重做日志不可用时（重做日志都是循环利用的），刷新脏页到磁盘；
数据库宕机后重启时，不需要重做所有的日志了。因为 Check Point之前的页都已经刷新到磁盘，数据库只需对Check Point后的重做日志进行恢复即可。从 而大大缩短恢复时间。
对于Innodb 而言，其实通过 LSN ( Log Sequence Number) 来比较版本的。 LSN 是一个8字节的数字。 每个页有LSN， 重做日志有LSN， CheckPoint 也有LSN。可以通过下述命令观察到
mysql> show engine innodb status\G;
.............
Log sequence number 92561351052
Log flushed up to 92561351052
Last checkpoint at 92561351052