MySQL中，既有redo log作为WAL，为什么还要change buffer？

先说一下普通一个数据修改的过程（这里不涉及到改主键索引或唯一索引B+树结构的，就说改普通字段的值）
第一步：INNODB要修改一个数据时，先判断内存（Buffer Pool）中有没有这个数据，有的话则直接修改内存。没有的话，先从磁盘中读到内存，再进行修改（先假设是这样）。
第二步：写redo log，将事务的状态标位prepare
第三步：写binlog第四步；将redo log中事务的状态标位commit到这里，一个事务已经结束了。
但是你会发现，数据压根就没落盘，只在Buffer Pool进行了相应的修改。而这些在内存中的数据（脏页）会在一段时间后因为某些原因才会被刷到磁盘中，那在这中间还没有刷到磁盘的过程中，则有可能发生断电，那还没有保存到磁盘中的buffer pool中的数据也就丢了，而redo log的作用，就是断电重启之后，用来恢复这部分的数据。（在我看来，redo log的作用仅此而已，有误的话可以指正）再回过头看第一步：如果是普通索引（非唯一索引），哪怕内存中没有这条数据，直接保存修改就行了，连去磁盘读取出这条数据这一步都不需要，节省了磁盘IO的时间。也就是上面说的流程中的第一步其实应该改为：如果仅仅修改了普通索引的话，内存中若有这条数据，则直接修改，若没这条数据，则先将修改的操作写到change buffer中。
回到问题：change buffer是做什么的？答：当然是为了提高效率的，但是有一定的局限性，基本上只能用在：数据在磁盘中而不在内存中，而这次修改不会涉及到改动主键索引以及唯一索引的结构 的情况之下。也就是优化了上面流程中的第一步。

答：什么时候不能够用change buffer呢？如果涉及到修改聚簇索引（主键索引）的结构时，比如新增一条字段，或者直接把主键的值给改了，类似于这样的操作，当然是用不了change buffer的。因为为了主键唯一性校验，必须先去磁盘中读有没有这条数据（或者内存中有对应的数据页也可以），才能进行更新，比如插入了一条id=5的数据，那当然要去判断一下有没有id = 5的数据，才能进行插入了，此时change buffer也就没有意义了。