InnoDB体系结构

InnoDB存储引擎的版本

早期的InnoDB存储引擎被包含于 MySQL数据库的二进制发型版本中，InnoDB存储引擎的版本也随着MySQL数据库的更新而更新。从MySQL5.1版本开始，MySQL数据库允许存储引擎开发商以动态方式加载引擎，这样存储引擎的更新可以不受MySQL数据库版本的限制。

InnoDB体系架构

InnoDB是多线程的模型，这么多的线程的目的就是负责刷新InnoDB内存池中的数据，保证内存池的数据和磁盘上的数据协调的工作。

后台线程

Master Thread： Master Thread是一个非常核心的后台线程，主要负责将缓冲池的数据异步刷新到磁盘，保证数据的一致性。包括脏页的刷新，合并插入缓冲UNDO页的回收等。
IO Thread： IO Thread的工作主要是负责响应InnoDB存储引擎中的大量的异步IO请求。IO Thread包括四种线程，分别是write、read、insertbuffer和log thread。同时write和read这两种线程的数量也可以不只一个，可以通过一些参数调整。
Purge Thread： 事物被提交后，其所使用的undolog可能不再需要，因此需要Purge Thread来回收已经使用并分配的undo页。
Page Cleaner Thread： 在InnoDB 1.2.X版本才开始引入的。其作用是将之前版本中脏页的刷新的任务从Master Thread分担出来。

内存

缓冲池： InnoDB存储引擎是基于磁盘存储的，并将其中的记录按照页的方式进行管理。在数据库系统中，由于CPU速度与磁盘数度之间的鸿沟，基于磁盘的数据库系统通常使用缓冲池技术提高数据库的整体性能。脏页重缓冲池刷新回磁盘的操作并不是在每次页发生更新时触发的，而是通过Checkpoint的机制刷新回磁盘。另外缓冲池的大小是可以调整配置参数调控的。一个数据库服务器的缓冲池还可以设置多个，增加效率。
LRU列表： LRU列表用来管理已经读到的页，对于这些缓冲页采用LRU算法管理，但这里有一个midpoint这个位置。所以刚读的页并不是立马加到首部，这个列表每个结点的存储内存来自Free列表。
Free列表： Free列表其实就是维持的一个存储结构的链表，这个链表结点数表示LRU列表可以存储的页的数量。
Flush列表： Flush列表中的也即为脏页，但注意这些脏页在LRU也有可能存在。不过LRU列表用来管理缓冲实现的可用性，Flush列表用阿里管理页刷新回磁盘，二者分开工作，互不影响。

重做日志缓冲：因为Write ahead Log的策略，会产生重做日志。但重做日志也是先被放到缓冲区，然后再按一定频率将其刷新到日志文件的。以解决IO和内存速率之间的不匹配。

额外的内存池：对一些数据结构本身的内存进行分配时，需要从额外的内存池中进行申请，当该区域的内存不够时，会从缓冲池进行申请。

checkpoint技术

checkpoint所做的工作就是将缓冲池的脏页按照一定条件刷回磁盘。
重做日志缓冲的情况，重做日志物理存储上的情况，以及上次checkpointd的情况都会有一个LSN码表示，以表征以表征脏页的刷新情况。当数据库发送宕机的时候，只需把还没写回磁盘的页利用重做日志进行恢复就可以了。

Master Thread工作方式

内部有主循环、后台循环、刷新循环、暂停循环这四个循环。以处理将日志缓冲刷新到磁盘，即使这个事物还没有提交。合并插入缓冲，刷新脏页到磁盘这几项功能。

InnoDB的关键特性

插入缓冲：在一个表上的非聚集索引不是顺序的，因此插入这样的索引的时候不着急每次都插入到物理存储中。而是先插入到插入缓冲中，然后再等一定的时间和情况将存在插入缓冲的索引进行适当的各自合并到一个操作中（此时就有可能多个索引在一个索引页中），以提高对于非聚集索引插入的性能。
两次写：当发生数据库宕机时，可能InnoDB存储引擎正在写入某个页到表中，这时这个页没有写完。这样就会存在部分写失效的问题，有的DBA也许会想用重做日志进行恢复。但重做日志中记录的都是对具体某个页的操作，所以此时的办法应该是在将某个页从缓冲池中写到物理存储之前，要在共享表空间里存在一个这个页的副本。以达到合理利用重做日志解决写失效的问题。
自适应哈希索引：同一个查询模式重复了很多次后，InnoDB存储引擎就会自动建立哈希索引以提高查询效率。
异步IO：用户可以在发出一个IO请求后立即再发出另一个IO请求，当全部IO请求发送完毕后，等待所有IO操作的完成，这就是异步IO。
刷新邻接页：当刷新一个脏页时，InnoDB存储引擎会检测该页所在区的所有页，如果是脏页，那么一起进行刷新。这样做的好处时，可以将多个IO请求合并为一个IO操作。