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

    如果要在这张表中插入一个 新记录(4,400)的话，InnoDB的处理流程是怎样的：

    1. 第一种情况是，这个记录要更新的目标页在内存中。这时，InnoDB的处理流程如下：
    • 对于唯一索引来说，找到3和5之间的位置，判断到没有冲突，插入这个值，语句执行结束；
    • 对于普通索引来说，找到3和5之间的位置，插入这个值，语句执行结束

    这样看来，普通索引和唯一索引对更新语句性能影响的差别，只是一个判断，只会耗费微小的 CPU时间。

    1. 第二种情况是，这个记录要更新的目标页不在内存中。这时，InnoDB的处理流程如下：
    • 对于唯一索引来说，需要将数据页读入内存，判断到没有冲突，插入这个值，语句执行结 束；
    • 对于普通索引来说，则是将更新记录在change buffer，语句执行就结束了。

    将数据从磁盘读入内存涉及随机IO的访问，是数据库里面成本最高的操作之一。change buffer 因为减少了随机磁盘访问，所以对更新性能的提升是会很明显的。

    change buffer的使用场景

    现在有一个问题就是：普通 索引的所有场景，使用change buffer都可以起到加速作用吗？

    因为merge的时候是真正进行数据更新的时刻，而change buffer的主要目的就是将记录的变更动 作缓存下来，所以在一个数据页做merge之前，change buffer记录的变更越多（也就是这个页面 上要更新的次数越多），收益就越大。

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

    索引选择和实践

    其实，这两类索引在查询能力上 是没差别的，主要考虑的是对更新性能的影响。所以，我建议你尽量选择普通索引。

    如果所有的更新后面，都马上伴随着对这个记录的查询，那么你应该关闭change buffer。而在 其他情况下，change buffer都能提升更新性能。

    如果要简单地对比这两个机制在提升更新性能上的收益的话，redo log 主要节省的是随 机写磁盘的IO消耗（转成顺序写），而change buffer主要节省的则是随机读磁盘的IO消 耗。