Change Buffer


InnoDB在Buffer Pool中开辟了一块内存，用来存储变更记录，为了防止异常宕机丢失缓存，当事务提交时会将变更记录持久化到磁盘（redo log），等待时机更新磁盘的数据文件（刷脏），用来缓存写操作的内存，就是Change Buffer
Change Buffer默认占Buffer Pool的25%，最大设置占用50%，写多读少的业务，才需要调大这个值，读多写少的业务，25%其实也多了。

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

  • 主键如果是自增的，只需要读取顺序读取磁盘中的页，然后插入最新的行即可。主键如果是非自增的或者是自己设置的值，那么可能需要做一次随机磁盘IO操作，读取到对应的页，做一下唯一性判断，然后插入数据即可。
  • 针对非主键索引中的唯一索引，大概率需要做随机磁盘IO读取，然后判断唯一性，再插入对应的行。
    所以对于主键索引和非主键的唯一索引，因为有唯一性判断，所以更新操作时，必须要从磁盘中读取数据页，判断唯一性，然后才能确定这个更新操作是否成功，即这个磁盘的IO操作是不可避免的。
  • 对于非唯一索引来说，其实步骤也是类似的。但是因为不需要做唯一性判断，所以为了提高更新的性能，Mysql给出的解决方案就是使用change buffer来保存对非唯一索引的更新。也就是说，当需要更新非唯一索引时，直接操作change buffer，成功即可返回。

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

  • 被动：在后续的真正需要读这个非唯一索引时，把索引的数据页从磁盘读取到内存中，再通过change buffer做一个merge操作，merge操作以后，内存中的数据页就是最新的了。（事务提交）
  • 主动：innoDB引擎中有线程会主动的定期做merge操作（默认每1秒）

业务实践


利用普通索引的change buffer特性，当业务场景中的写远大于读时，常见场景为日志表，当某些列必须建立索引时，可以考虑建立普通索引，提高写入性能。
如果业务场景的写之后立即伴随读，如果列的值是唯一的
那么其实建立普通索引是不合适的，因为写的过程，虽然利用了change buffer暂时提高了写的性能，但是在读的时候还是需要磁盘IO。可以考虑建立唯一索引，在索引写的时候，就提前读取数据到缓冲池中，提高读的性能。