当需要更新一个数据页时，如果数据页在内存(buffer pool)中就直接更新好了(还要记下redo log)，
但是 如果这个数据页还没有在内存中,并且不是唯一索引不用查是不是重了, InooDB 会将这些更新操作缓存在 change buffer 中(同样要记下redo log),
这样就不需要 从磁盘中 读入这个数据页了来更新了
好处:
- 语句的执行速度会得到明显的提升。
- 数据读入内存是需要占用 buffer pool 的，还能够避免占用内存，提高内存利用率。
虽然名字叫作 change buffer，实际上它是可以持久化的数据。也就是说，change buffer 在内存中有拷贝，也会被写入到磁盘上。
将 change buffer 中的操作应用到原数据页，得到最新结果的过程称为 merge。
时机是:
- 访问这个数据页会触发 merge
- 系统有后台线程会定期 merge。
- 在数据库正常关闭（shutdown）的过程中，会执行 merge 操作。
使用场景
change buffer 只限于用在普通索引的场景下，而不适用于唯一索引。
对唯一索引, 必须先查询看有没有已经存在, 才能改, 所以必须先把数据从磁盘读入内存, 这步不能省
那么，现在有一个问题就是：普通索引的所有场景，使用 change buffer 都可以起到加速作用吗？
merge 的时候是真正进行数据更新的时刻，而 change buffer 的主要目的就是将记录的变更动作缓存下来，所以在一个数据页做 merge 之前，change buffer 记录的变更越多（也就是这个页面上要更新的次数越多），收益就越大。
因此，对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时 change buffer 的使用效果最好。
常见的就是 账单类、日志类的系统。
反过来，写入之后马上会做查询，那么即使满足了条件，将更新先记录在 change buffer，立即触发 merge 过程。
随机访问 IO 的次数不会减少，反而增加了 change buffer 的维护代价。
和 redo log 一起看
表t 在k上有普通索引,以下只查id和k 是覆盖索引
insert into t(id,k) values(id1,k1),(id2,k2);
假设k1 所在的数据页在内存 (InnoDB buffer pool) 中，k2 所在的数据页不在
1.k1 所在的Page 1 在内存中，直接更新内存；
2.k2 所在的Page 2 没有在内存中，就在内存(change buffer区域)记录下“我要往 Page 2 插入一行”这个信息(省了读磁盘了)
3.4. 将上述两个动作记入 redo log 中(就这么一次顺序写磁盘)
发现, 执行这条更新语句的成本很低，就是写了两处内存，然后写了一处磁盘（两次操作合在一起写了一次磁盘），而且还是顺序写的。
图中的两个虚线箭头，是后台操作(空闲时或者必须时写入磁盘)，不影响更新的响应时间。
接着要读取这2个刚更新的行
select * from t where k in (k1, k2)
k1 本来就在内存中, 之前内存也更新了, 所以直接拿内存的就是对的
k2 只有id和k 在内存的change buffer区域, 其他列的数据不在, 所以必须读磁盘, 然后和change buffer区域记录的修改过的最新数据结合, 返回正确数据(这会触发change buffer的一次merge)
redo log 节省的是随机写磁盘的 IO 消耗（虽然也是磁盘,但是转成顺序写日志）
change buffer要节省随机读磁盘的 IO 消耗。如果没有它, 要先把数据从磁盘读入内存, 再在内存改, 有他省了一步
