Innodb关键特性

Innodb存储引擎关键特性包括：

• 插入缓冲 (Insert Buffer)
• 两次写 (Double Write)
• 自适应哈希索引 (Adaptive Hash Index)
• 异步IO (Async IO)
• 刷新领接页（Flush Neighbor Page）

插入缓冲 Insert Buffer

Innodb引擎开创性地设计了Insert Buffer，对于非聚集索引的插入或更新操作不是一次性地插入到索引页中，而是先判断插入的非聚集索引页是否在缓冲池中，若在则插入，不在，则先放到Insert Buffer中（对应有磁盘存储，但是因为是顺序的，效率较高），然后再通过merge操作合并Insert Buffer和辅助索引页，以提高对于非聚集索引插入的性能。

Insert Buffer只是针对非聚集索引的插入和更新操作，使用Insert Buffer需要同时满足两个条件：

• 索引是辅助索引
• 索引不是唯一索引

对于聚集索引（innodb数据页）和唯一的聚集索引都不能用Insert Buffer，原因：

• 聚集索引（主键索引）大多数是自增的，即有序的，符合“磁盘顺序读写不差于随机存储设备”
• 唯一索引需要判断插入记录的唯一性，同样有“离散读”的问题，导致Insert Buffer失去意义

Insert buffer实现

Insert Buffer的数据结构是一棵B+树，在MYSQL 4.1之前的版本中每张表都有一棵Insert Buffer B+树，在现在的版本中，全局维护一棵B+树。非叶子节点存放search key：space+marker+offset。space表示待插入记录锁在表的表空间id，每张表都有一个唯一的space id，marker是兼容老版本的insert buffer，offset表示页所在的偏移量。所以一个非唯一的辅助索引要插入到页时，如果这个页不在缓冲池中，那么首先根据上述规则构造一个search key，然后插入到insert buffer中，插入的记录为search key(space+marker+offset)+metadata+secondary index record，metadata记录了一些插入的其它元数据信息。

Insert buffer的合并

insert buffer什么时候合并到真正的索引树中去呢？概括的来说，Merge Insert Buffer的操作可能发生在以下几种情况：

• 辅助索引页被读取到缓冲池时；（查询会要求缓冲索引页）
• Insert Buffer Bitmap页追踪到该索引insert buffer已无可用空间时
• Master Thread定时合并（每次Master Thread并非合并所有的页，会根据算法选择一定比例的页合并）

两次写

当数据库发生宕机后，内存的数据还没有写到磁盘中，这时候该怎么恢复数据呢？我们当然会想到redo log，但是redo log记录的是对页的物理操作，如果一个页大小为16KB，只写入了前4KB，之后发生宕机，依照redo log来恢复数据是没有意义的，因为这个页本身发生了部分写导致的损坏。为了避免部分写导致的数据丢失的情况，innodb采取了double write技术，在对缓存池的脏页进行刷新的时候，并不直接写入磁盘，而是先将脏页复制到doublewrite buffer中，之后将doublewrite buffer分两次，顺序的写入到物理磁盘上，然后调用fsync函数，同步磁盘。（当fsync刷新脏页发生部分写时，通过doublewrite和redolog恢复。如果doublewrite写入磁盘本身发生问题，就直接通过redolog恢复，没有部分写的问题）。

doublewrite大小为2MB，磁盘上在共享表空间的连续的128个页，即2个区，因此也是连续的，顺序读写的开销也不是很大。参数skip_innodb_doublewrite可以禁止用doublewrite功能，在slave server关闭doublewrite可以提高性能，不过对于需要提供高可用性的主服务器（master server），应该开启doublewrite功能。

有些文件系统本身就提供了部分写失效的防范机制，如ZFS文件系统，这种情况用户就不用启用double write了。

自适应哈希索引

在生产环境中，B+树的高度一般为3-4层，故需要3-4次查询。一般情况下哈希的查找时间复杂度为O(1)。innodb引擎会监控表上各索引页的查询，如果观察到建立哈希索引可以带来速度提升，则建立哈希索引，称之为自适应哈希索引（Adaptive Hash Index, AHI）。AHI通过缓冲池的B+树页构造，因此建立速度很快，而且也不需要对整张表构建哈希索引，只需要对热点页构建。

AHI构建的条件：

• 连续访问模式一样，例如联合索引（a，b）WHERE a=xxx 和 WHERE a=xxx b=xxx不一样
• 以该模式访问了100次
• 页通过该模式访问了N次，N=页中记录*1/16

哈希相比于B+树不是sorted，所以对于范围查询是不能使用哈希索引的。根据innodb存储引擎官方文档显示，启用AHI后，读取和写入速度可以提高2倍，辅助索引的连接索引可以提高5倍。AHI的设计思想是数据库的自优化（self-tuning），即不需要DBA的介入对数据库的优化。

异步IO

相比于Sync IO，用户可以在发出一个IO请求后立即再发出另一个IO请求，当全部IO请求发送完毕后，等待IO操作的完成。AIO不仅让IO操作可以并行的进行，充分的利用计算机的资源，AIO的另一个优势是可以进行IO Merge操作，将多个IO合并成一个IO，提高IOPS的性能。

在innodb 1.1.x之前，AIO通过存储引擎中代码来模拟实现，在这个版本之后，innodb提供了内核级别AIO的支持。并不是所有操作系统提供Native AIO的支持，不支持的话依旧只能使用模拟的方式。官方的测试显示，启用Native AIO比模拟方式速度可以提高75%。（mac osx系统未提供Native AIO）

刷新领接页

当刷新一个脏页时，innodb存储引擎会检测该页所在区（extent）的所有页，如果是脏页则一起刷新，这样可以通过AIO的IO合并带来性能提升（顺序读写），故该机制在传统机械硬盘下有着显著的优势。但是刷新领接页会带来两个问题：

• 是不是把不怎么脏的页刷新了，该页会很快又变成了脏页？
• 固态硬盘有着较高的IOPS，是否还需要这个特性？

现在计算机的发展中，CPU，GPU以及网络的发展要远远迅速于存储设备的发展，机械硬盘成为了计算机性能的一个瓶颈，但是将来随着廉价的Flash Disk的发展，也许固态硬盘会越来越多的使用。对于固态硬盘，建议将参数innodb_flush_neighbors设置成0，关闭刷新领接页的特性。