ChangeBuffer对于更新过程有显着的性能提升。更新数据时，如果数据页在内存中，则直接更新。如果更新数据的内存页不在内存中，数据库引擎会将更新操作缓存在ChangeBuffer中，不影响数据的一致性。,这样就不需要从磁盘中读取数据页了,下次查询数据页的时候再从磁盘中读取数据页,然后执行记录在ChangeBuffer中的数据页相关的操作,这样为了保证数据，准确的说，这个过程也叫merge。我们先将更新操作写到ChangeBuffer中，减少磁盘读取，更新语句的执行速度会明显提升。将更新操作记录在ChangeBuffer中，然后合并在一起，减少了读入内存的数据，提高了内存利用率。ChangeBuffer的合并会在查询相关数据页时触发，系统后台线程也会周期性合并。正常关闭数据库时，会先合并，再关闭数据库。为什么唯一索引不能使用ChangeBuffer？唯一索引每次更新时，都会先查询要插入的数据是否已经存在。这就需要将数据页读入内存，检查是否违反了唯一性约束。如果数据页已经插入内存，读入内存后，直接更新内存即可。假设我们要往一张表中插入一条数据，我们来看看唯一索引和普通索引的处理流程有什么不同。我们来看两种情况：待更新的数据页在内存中和待更新的数据页不在内存中。1.要更新的数据页在内存中。唯一索引：先找到要插入的位置，判断是否有冲突，然后插入数据，执行结束。普通索引：先找到要插入的位置，插入数据，结束执行。在这种情况下，唯一索引和普通索引对语句执行速度的影响相差不大，可以忽略不计。2.要更新的数据页不在内存中。唯一索引：先将数据页读入内存，然后判断要插入的位置是否有冲突，然后插入数据，执行结束。普通索引：将更新记录写入ChangeBuffer，执行结束。此时的唯一索引涉及随机磁盘访问，这也是最昂贵的操作之一。相应地，将普通索引写入ChangeBuffer可减少随机磁盘访问并显着提高性能。所有普通索引都可以使用ChangeBuffer吗？至此我们知道ChangeBuffer可以加速普通索引的更新操作，那么是不是所有的普通索引都可以使用ChangeBuffer来加速呢？这个时候我们就需要针对具体的业务，不同的场景使用不同的策略。ChangeBuffer可以看作是缓存变更记录。因此，合并前ChangeBuffer中记录的变更记录越多，性能提升越大。所以对于写多读少的业务场景，比如文件系统，日志系统，非常有效。对于写入后马上查询的业务场景，使用ChangeBuffer。记录完更新记录后，查询很快就会开始合并。这样既不会减少随机磁盘访问，也会增加写ChangeBuffer。这个地方ChangeBuffer是反过来的。比如我们OMS系统的订单表，有些操作写入后会立即执行，所有的操作都需要查询。综上所述，ChangeBuffer主要是为了提高更新操作的性能。建议尽量选择普通索引。如果写入后查询业务场景，则应关闭ChangeBuffer。除了这种业务场景，ChangeBuffer可以提升性能。
