Change Buffer与innodb_force_recovery=4

一、关于innodb_force_recovery

熟悉mysql的人一定熟悉innodb_force_recovery这个参数，如果数据库crash，再次启动的时候innodb会对innodb表进行恢复，恢复成功，数据库正常启动，如果恢复失败，数据库将无法启动。根据经验，innodb_force_recovery=4这个参数相当管用，最近用于恢复了一个数据库，步骤网上都有：

1、在/etc/my.cnf中增加：
 [mysqld]
innodb_force_recovery = 4
2、重启MySQL。
3、mysqldump导出所有的表

现在有了dmp文件了，新建一个mysql环境执行导入即可。

看看mysql5.6的官方建议：

4          (SRV_FORCE_NO_IBUF_MERGE)

Prevents insert buffer merge operations. If they would cause a crash,does not do them. Does not calculate table statistics. This value can permanently corrupt data files. After using this value, be prepared to drop and recreate all secondary indexes. As of MySQL 5.6.15, sets InnoDB to read-only.

这里可以看到，文档说用这个值启动数据库可能会永久地破坏数据文件，并且建议删除和重建所有二级索引，因此，得到dmp后还是换个数据环境玩吧。

二、关于insert buffer merge

准确说，在mysql 5.5后，应该叫change buffer merge了。首先需要知道什么是change buffer？

还是先看看mysql5.6的官方文档：

下面一段话很好地解释了什么是change buffer:

Similarly, deletes and updates may affect secondary index        pages that are not adjacently located in an index tree. Merging        cached changes at a later time, when affected pages are read        into the buffer pool by other operations, avoids substantial        random access I/O that would be required to read-in secondary        index pages from disk.

Periodically, the purge operation that runs when the system is        mostly idle, or during a slow shutdown, writes the updated index        pages to disk. The purge operation can write disk blocks for a        series of index values more efficiently than if each value were        written to disk immediately.

从这段话可以看到，change buffer的核心思想是为了降低对二级索引页的随机访问频率。

并不是每次对二级索引页的删除或者更新都会去从磁盘把相应page读到内存，而是会稍微“等”一下，看是否其它操作也会用到这个页，到时候就可以把这些脏数据“融合”在一起了，然后周期性purge，写回到磁盘。

这里就可以理解为什么当我们用innodb_force_recovery = 4恢复数据库后，官方文档建议重建所有二级索引了，因为二级索引的缓存有问题，无法和磁盘同步到一致状态了。

注：

类似机制，其实在oracle里面早就有了，也就是说事务提交的时候，一定会写日志到磁盘，但缓存里的脏数据块未必会马上写到磁盘，如果数据写磁盘要跟事务提交同步，那么io效率必然会很差。

本文出自 “” 博客，请务必保留此出处