change buffer 的作用

当需要更新一个数据页时，如果数据页在内存中就直接更新，而如果这个数据页还没有在内存中的话，在不影响数据一致性的前提下，InooDB 会将这些更新操作缓存在 change buffer 中，这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行 change buffer 中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正确性。

需要说明的是，虽然名字叫作 change buffer，实际上它是可以持久化的数据。也就是说，change buffer 在内存中有拷贝，也会被写入到磁盘上。

将 change buffer 中的操作应用到原数据页，得到最新结果的过程称为 merge。除了访问这个数据页会触发 merge 外，系统有后台线程会定期 merge。在数据库正常关闭（shutdown）的过程中，也会执行 merge 操作。

显然，如果能够将更新操作先记录在 change buffer，减少读磁盘，语句的执行速度会得到明显的提升。而且，数据读入内存是需要占用 buffer pool 的，所以这种方式还能够避免占用内存，提高内存利用率。

使用条件

没有唯一索引:对于唯一索引来说,所有的更新操作都要先判断这个操作是否违反唯一约束性,而这必须要将数据页读入内存才能判断,如果都已经读入到内存了,那就没有必要时用change buffer 了.

使用场景

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

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

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

change buffer 的内部构造

ibuf tree

change buffer的物理上是一颗普通的btree，存储在ibdata系统表空间中。

ibuf btree通过三列(space id, page no , counter)作为主键来唯一决定一条记录，其中counter是一个递增值，目的是为了维持不同操作的有序性，例如可以通过counter来保证在merge时执行如下序列时的循序和用户操作顺序是一致的：INSERT x, DELETE-MARK x, INSERT x。

ibuf btree最大默认为buffer pool size的25%，当超过25%时，可能触发用户线程同步缩减ibuf btree。为何要将ibuf btree的大小和buffer pool大小相关联呢 ？ 一个比较重要的原因是防止ibuf本身占用过多的buffer pool资源。

ibuf 位图

由于ibuf缓存的操作都是针对某个具体页面的，因此在缓存操作时必须保证该操作不会导致空页或索引分裂。

• 针对第一种情况，即避免空页，主要是对purge线程而言，因为只有purge线程才会去真正的删除二级索引上的物理记录。在准备插入类型为IBUF_OP_DELETE的操作缓存时，会预估在apply完该page上所有的ibuf entry后还剩下多少记录（ibuf_get_volume_buffered），如果只剩下一条记录，则拒绝本次purge操作缓存，改走正常的读入物理页逻辑。

• 针对第二种情况,索引分裂,InnoDB通过一种特殊的page来维护每个数据页的空闲空间大小，也就是ibuf bitmap page，该page存在于每个ibd文件中，具有固定的page no。ibuf_bitmap_page_get_bits函数根据space id 和page no 获取对应的bitmap page，找到空闲空间描述信息；如果本次插入操作可能超出限制，则从当前cursor位置附近开始，触发一次异步的ibuf merge，目的是尽量将当前page的缓存操作做一次合并。