InnoDB存储引擎有三大特性

InnoDB存储引擎有三大特性非常令人激动，它们分别是插入缓冲、两次写和自适应哈希

innodb 关键特性其中之二
写缓存是为了提升写性能，两次写为了提升可靠性
change buffer
innodb引擎是索引组织表，所有记录都放在聚集索引里，因此其辅助索引中的记录地址存放的主键的键值。
它是一种特殊的数据结构，缓存对二级索引页面的更改并且这些页面不在buffer pool中。缓存的changes可能由insert、delete和update 的结果导致。稍后在页面被其他读取操作加载到 buffer pool 的时候合并。
简言之:change buffer 的主要目的是将对二级索引的数据操作缓存下来，以此减少二级索引的随机IO，并达到操作合并的效果。
写缓冲的目的是降低写操作的磁盘IO，提升数据库性能。

它是一种应用在非唯一普通索引(二级索引)页不在缓冲池中，对页进行了写操作，并不会立即将磁盘页加载到缓冲池，而仅仅记录缓冲变更(buffer changes)缓存到 ibdata里的一个btree (ibuf)，等未来数据被读取时，再将数据合并(merge)恢复到缓冲池中的技术。写缓冲的目的是降低写操作的磁盘IO,提升数据性能。

加入写缓冲优化后，流程优化为：

（1）在写缓冲中记录这个操作，一次内存操作；

（2）写入redo log，一次磁盘顺序写操作；

其性能与，这个索引页在缓冲池中，相近。

画外音：可以看到，40这一页，并没有加载到缓冲池中。

什么时候适合使用写缓冲，如果：

（1）数据库大部分是非唯一索引；

（2）业务是写多读少，或者不是写后立刻读取；

可以使用写缓冲，将原本每次写入都需要进行磁盘IO的SQL，优化定期批量写磁盘。
相关参数
参数：innodb_change_buffer_max_size
介绍：配置写缓冲的大小，占整个缓冲池的比例，默认值是25%，最大值是50%。
画外音：写多读少的业务，才需要调大这个值，读多写少的业务，25%其实也多了。
参数：innodb_change_buffering
介绍：配置哪些写操作启用写缓冲，可以设置成all/none/inserts/deletes等。

change buffer 是innodb的一种特殊结构，其本质上是一棵存在于ibdata的btree.当修改用户表空间的二级索引页时，如果对应的page不在内存中，该操作将可能被记录到change buffer中，从而减少了二级索引的随机io.并达到了合并更新的效果。
随后当对应的page被读入内存时，会进行一次merge操作;后台master线程也会定期发起merge.

当需要更新一个数据页时，如果数据页在内存中就直接更新；而如果这个数据页还没有在内存中的话，在不影响数据一致性的前提下，InnoDB 会将这些更新操作缓存在 change buffer 中。

这样就不需要从磁盘中读入这个数据页了，在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行 change buffer 中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正确性。

注意唯一索引的更新就不能使用 change buffer，实际上也只有普通索引可以使用。

适用场景：

• 对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时 change buffer 的使用效果最好。这种业务模型常见的就是账单类、日志类的系统。

• 反过来，假设一个业务的更新模式是写入之后马上会做查询，那么即使满足了条件，将更新先记录在 change buffer，但之后由于马上要访问这个数据页，会立即触发 merge 过程。这样随机访问 IO 的次数不会减少，反而增加了 change buffer 的维护代价。

double write buffer
doublewrite（两次写）
简单说，就是在写数据页(块)之前，先把这个数据页写到一块独立的物理文件位置(ibdata),然后再写到数据页。这样在宕机重启时，如果出现数据页损坏，那么在应用redo log之前，需要通过该页的副本来还原该页，然后再进行redo log重做，这就是 double write.
MySQL有很强的数据安全性机制：
（1）在异常崩溃时，如果不出现“页数据损坏”，能够通过redo恢复数据；
（2）在出现“页数据损坏”时，能够通过double write buffer恢复页数据；
double write buffer：
（1）不是⼀个内存buffer，是⼀个内存/磁盘两层的结构，是InnoDB⾥On-Disk架构⾥很重要的⼀部分；（2）是⼀个通过写两次，保证页完整性的机制；