InnoDB存储引擎关键特性

• Insert Buffer 和 Change Buffer
• 两次写
• 自适应哈希索引 AHI
• 异步IO
• 刷新临界页

InnoDB存储引擎包括：

• 插入缓冲 Insert Buffer
• Change Buffer
• 两次写 Double Write
• 自适应哈希索引 Adaptive Hash Index
• 异步IO Async IO
• 刷新临界页 Flush Neighbor Page

Change Buffer 其实可以理解为就是Insert Buffer的升级版。主要的作用就是提高更新操作的效率，当我们执行一条更新的sql语句，我们除了更新Buffer Pool中的数据页以外还需要更新该记录所对应的索引页，如果需要修改的索引页刚好目前就存在Buffer Pool中 就可以直接修改索引页。但如果不存在嘞！那就需要先从磁盘中把索引页读取出来放在Buffer Pool中进行相应的修改，众所周知，一次磁盘IO的性能消耗是很高的，更何况一次更新操作还不止仅仅读取一个索引页，很多情况会读取很多索引页，这样就会进行很多次磁盘io，还有就是Buffer Pool的利用率也不高。

InnoDB存储引擎就使用了Insert Buffer / Change Buffer 的机制来解决这个问题。 Insert Buffer 其实是一颗B+ Tree，当执行更新操作后，首先会判断索引页是否在缓冲池中，如果在就进行修改，否则就保存在一个Insert Buffer对象中，在保存到 Insert Buffer 这一颗B+ Tree中，在以一定的条件进行Merge 合并操作来修改磁盘中的索引页。

能进入Insert Buffer的还有一个前提条件：索引必须是非唯一非聚集索引

Merge操作的触发条件 ，更详细的内容请点击查看

• Master Thread 以秒为单位进行合并操作
• 当该非唯一非聚集索引再一次被使用时，也就是某条查询语句使用到了该索引，将该索引页从磁盘中读取出来至Buffer Pool中的时候
• Change Buffer底层结构就是一颗B+ Tree ，刚这颗B+ Tree可用空闲区域少于了总容量的1/32

Insert Buffer 和 Change Buffer 给InnoDB存储引擎带来的是性能上的提升，两次写 Double Wirte给InnoDB存储引擎带来的就是数据页的可靠性。
问题就是，一个16KB的数据页，经过Check Point机制将Buffer Pool中的脏页刷新回磁盘，一页的数据还没有全部持久化完成，也就是假如16KB的数据 持久化了4KB，然后数据库就宕机了，这样就会造成数据丢失。InnoDB存储引擎采用了两次写的机制来解决此问题。

具体的运行机制：在对脏页进行刷新时，并不是直接刷新回磁盘，而是先通过memcpy函数将脏页先复制到doublewrite buffer中，之后在分两次，一次1MB顺序写入到共享表空间的物理磁盘上，然后马上调用fsync函数同步磁盘。如果操作系统在写入磁盘的过程中Mysql崩溃了，
在恢复过程中，InnoDB存储引擎可以从共享表空间中的doublewirte中找到该页的副本，将其复制到表空间文件，在应用Redo Log。

哈希索引的查找速度是非常快的，InnoDB存储引擎会根据访问的频率和模式来自动地为某些热点页建立哈希索引，对一页的访问模式必须是一样的。比如 where a=XXX ； 和 where a=XXX and b=XXX ; 这就是不同的两种访问模式。就不会创建AHI。
此外AHI还有如下的要求：

• 以该模式访问了100次
• 页通过该模式访问了 页的总记录数*1/16 次数

需要注意的是 哈希索引 只能够用来搜索等值的查询

当前数据库系统都是采用异步IO的方式来处理磁盘操作。异步IO的另一个优势就是可以进行io 的 merge操作，也就是将多个io合并为一个io，这样可以提高IOPS的性能。假如用户需要读取三页数据，并且这三页是连续的，同步IO就需要进行3次磁盘io操作，而异步io会判断这三页是否连续，如果是连续的那么异步io就会发送一个io请求，直接读取48KB的数据。

刷新临界页就是当刷新一个脏页时，InnoDB存储引擎会检测该页所在的区extent的所有页，如果是脏页就一起进行刷新。这个功能可以根据实际的情况考虑是否需要使用