change buffer（在 MySQL 5.6 之前叫 insert buffer，简称 ibuf ）是 InnoDB 5.5 引入的一种优化策略，若二级索引页不在 buffer pool 中，则将针对二级索引页的操作暂时缓存起来，等到该页从磁盘读到 buffer pool 中时再批量的（batch）apply 这些操作，从而达到减少磁盘 I/O 的目的。具体一点就是： 事务 1 执行写操作（e.g update），但针对的二级索引页 P1 并不在 buffer pool 中 于是 client 1 将这个操作缓存到 change buffer 里，即添加一个 entry（ibuf insert） 事务 2 需要读操作，将 P1 读到 buffer pool 中 将 change buffer 里相关的缓存的操作全部合并（merge）至 P1（ibuf merge） 将 P1 返回给用户线程
大家好，我是田哥 今天来和大家分享MySQL的三个日志文件，可以说 MySQL 的多数特性都是围绕日志文件实现，而其中最重要的有以下三种： redo 日志 undo 日志 binlog 日志 比如更新语句的流程会涉及到 undo log（回滚日志）、redo log（重做日志） 、binlog （归档日志）这三种日志： undo log（回滚日志） ：是 Innodb 存储引擎层生成的日志，实现了事务中的原子性，主要用于事务回滚和 MVCC。 redo log（重做日志） ：是 Innodb 存储引擎层生成的日志，实现了事务中的持久性，主要用于掉电等故障恢复； binlog （归档日志） ：是 Server 层生成的日志，主要用于数据备份和主从复制；
电商业务场景，随着平台订单规模的日益增长，订单现有的存储已经没办法支撑后面业务的发展。在得物五彩石项目的时候就对订单进行了分库分表的拆分，为了解决分库分表后卖家维度的查询问题，单独创建了一个卖家维度的订单库。 目前订单分为买家和卖家两个库，卖家库的数据是通过监听买家库binlog异构出来的一个库。现在订单主要有两张表，分别是订单的主表和子表。 在异构的逻辑中，我们会对这两张表的binlog消息进行处理，异构成我们的卖家订单表。在监听到插入的消息时，只会处理子表的插入消息，其余需要补充的主订单表数据直接查询主表。
