mysql change_MySQL-对Change Buffer的理解

Change Buffer的处理过程

对非唯一的普通索引的新增或更新操作，如果索引B+树的需要新增或更新的数据页不在内存中，则直接更新change buffer，等到后面需要使用这个数据页(真正读到内存中来)的时候，再根据change buffer在内存中做merge合并操作。

Change Buffer有什么好处？

先想想没有change buffer时候，在缓冲池中没有对应数据页时会怎么更新。概括来说，有两个步骤：

首先需要从磁盘中读取对应的数据页到内存中

然后更新内存中的数据页。

首先分析主键索引或者非主键索引中的唯一索引，插入或者更新的操作。

主键如果是自增的，只需要读取顺序读取磁盘中的页，然后插入最新的行即可。主键如果是非自增的或者是自己设置的值，那么可能需要做一次随机磁盘IO操作，读取到对应的页，做一下唯一性判断，然后插入数据即可。

针对非主键索引中的唯一索引，大概率需要做随机磁盘IO读取，然后判断唯一性，再插入对应的行。

所以对于主键索引和非主键的唯一索引，因为有唯一性判断，所以更新操作时，必须要从磁盘中读取数据页，判断唯一性，然后才能确定这个更新操作是否成功，即这个磁盘的IO操作是不可避免的。

对于非唯一索引来说，其实步骤也是类似的。但是因为不需要做唯一性判断，所以为了提高更新的性能，Mysql给出的解决方案就是使用change buffer来保存对非唯一索引的更新。也就是说，当需要更新非唯一索引时，直接操作change buffer，成功即可返回。

那么什么时候会真正更新数据页呢？有两种情况会触发：

被动：在后续的真正需要读这个非唯一索引时，把索引的数据页从磁盘读取到内存中，再通过change buffer做一个merge操作，merge操作以后，内存中的数据页就是最新的了。

主动：innoDB引擎中有线程会主动的定期做merge操作

业务实践

利用普通索引的change buffer特性，当业务场景中的写远大于读时，常见场景为日志表，当某些列必须建立索引时，可以考虑建立普通索引，提高写入性能。

如果业务场景的写之后立即伴随读，如果列的值是唯一的

那么其实建立普通索引是不合适的，因为写的过程，虽然利用了change buffer暂时提高了写的性能，但是在读的时候还是需要磁盘IO。可以考虑建立唯一索引，在索引写的时候，就提前读取数据到缓冲池中，提高读的性能。