INNODB引擎的4大特性

1、插入缓存
2、二次写
3、自适应哈希
4、预读
一、插入缓存（insert buffer）
插入缓冲（insert Buffer/Change Buffer）：提升插入性能，change buffering是insert buffer的加强，Insert buffer只针对Insert有效，Change buffer对Insert、delete、update（delete+insert）、purge都有效
只对于非聚集索引（非唯一）的插入和更新有效，对于每一次的插入不是写到索引页中，而是先判断插入的非聚集索引页是否在缓冲池中，如果在则字节插入；若不在，则先放到insert Buffer中，在按照一定的效率进行合并操作，在写会Disk。这样通常能将多个插入合并到一个操作中，目的还是为了减少随机IO带来性能损耗。

使用插入缓冲的条件：

1. 非聚集索引
2. 非唯一索引

Change Buffer是作为Buffer pool中的一部分存在。Innodb_change_buffering参数缓存所对应的操作：（update会被认为是delete+insert）
Innodb_change_buffering：设置的值有：Insert、deletes、purges、changes（Inserts和deletes）、all（默认）、none。

all:默认值，缓存Insert，delete，purges操作。
Inserts：缓存Insert操作。
deletes:缓存deletes操作。
Changes：缓存Insert和delete操作。
purges:缓存后台之心的物理删除操作。

可以通过参数控制其使用的大小：
Innodb_change_buffer_max_size,默认是25%，即缓冲池的1/4，最大可设置为1/2。当MySql实例中有大量的修改操作时，要考虑怎大Innodb_change_buffer_max_size

在一定频率下进行合并，所谓的频率是什么条件？

1. 辅助索引页被读取到缓存池中，正常的select先检查Insert Buffer是否有 该非聚集索引页的存在 ，若有则合并插入。
2. 辅助索引页没有可用空间，空间小于1/32页的大小，则会强制合并操作。
3. Master Thread每秒和每10秒的合并操作。

二、二次写（Double wite）
DoubleWrite缓存是位于系统表空间的存储区域，用来缓存Innodb的数据页从Innodb Buffer pool中flush之后并写入到数据文件之前，所以当操作系统或者数据库进程在数据页写磁盘的过程中崩溃，Innodb可以在DoubleWrite缓存中找到数据页的备份而用来执行Crash恢复。数据页写入到DoubleWrite缓存的动作所需要的的IO消耗，此写入操作会以一次大的连续块的方式写入

在应用（apply）重做日志前，用户需要一个页的副本，当写入失效发生时，先通过页的副本来还原该页没在进行重做，这就是Double Write

Double Write组成：

1. 内存中的double write buffer大小2M
2. 物理磁盘上共享表空间中连续的128个页，即2个区（extend），大小同样为2M
3. 对缓冲池的脏页进行刷新时，不是直接写磁盘，而是会通过memcpy() 函数将脏页相纸到内存中的Double Write Buffer，之后通过Double Write再分两次，每次1M顺序地写入 共享表空间的物理磁盘上，在这个工程中，因为Double Write页是连续的，因此 这个过程是顺序写的，开销并不是很大。在完成Double Write页的写入后，再讲Double Write Buffer 中的页写入各个表空间文件中，此时的写入这是离散的。如果操作系统再将页写入磁盘的过程中发生了崩溃，在回复过程中，Innodb可以从共享表空间中的Double Write中找到该页的一个副本，将其复制到表空间文件，再应用重做日志。

三、自适应哈希索引（AHI）
Adaptive Hash index属性使得Innodb更像是内存数据库，该属性通过Innodb_adaptive_hash_index开启，也可以通过——skip-innodb_adaptive_hash_index参数关闭。
注：可以关闭自适应Hash
生成Hash索引的条件比较苛刻

1. 索引是否被 访问了17次
2. 索引中的某个页已经被访问了100次
3. 访问模式必须是一样的。
   例如对于（a、p）访问模式情况：
   where a = xxx
   where a = xxx and b = xxx

Innodb存储引擎会监控对表上二级索引的查找，如果发现某二级索引被频繁访问 ，二级索引成为 热数据，建立哈希索引可以代理速度的提升。
经常访问的二级索引数据会自动被生成到hash索引里面去（最近连续被访问三次的数据），自适应哈希索引通过缓冲池的B+树构造而来，因此建立的速度很快。
哈希（Hash）是一种非常快的等值查找方法，一般情况下这种查找的时间复杂度为O(1) 即一般仅需要一次查找就能定位数据，而B+树的查找次数，取决于B+树的高度，在生产环境中，B+树的高度一般是3、4层，故需要3-4次的查询。

Innodb会监控对表上个索引页的查询，如果观察到简历哈希索引可以带来速度提升，则自动建立哈希索引，称之为自适应哈希索引（Adaptive Hash Index,AHI）

特点：

1. 无序，没有树高
2. 降低对二级索引树的频繁访问资源，索引树高<=4 访问索引：访问树，根节点，叶子节点。
3. 自适应
   缺陷：
4. jash自适应索引会占用Innodb buffer pool
5. 自适应hash索引只适合搜索等值的查询，如select * from table where index_col='xxx' 而对于其他查找类型，如范围查找，是不能使用的。
6. 极端情况下，自适应hash索引才有比较大的意义，可以减低逻辑读。

四、预读
Innodb使用两种预读算法来提高I/O性能：线性预读（linear read_ahead）和随机预读（randomread-ahead）为了区分这两种预读的方式，我们可以吧线性预读放到以extent为单位，而随机读放到exent中的page为单位，线性预读着眼于降下一个extent提前读取到 buffer pool中，而随机预读着眼于extent中的剩余的page提前读取到buffer pool中。

原文为：