你插入MySQL的数据真的存到表里了么？

现在有这么一个问题：当你执行一条insert语句之后，插入的数据就已经保存在磁盘中了么？

答案是不一定，那是为什么呢？首先来了解一下MySQL在InnoDB存储引擎中，数据是怎么存储的。

1. InnoDB数据存储单元

同大多数数据库一样，InnoDB有页（Page)的概念（也可以称为块）,页是InnoDB磁盘管理的最小单位。在InnoDB存储引擎中，默认每个页的大小为16 KB。而从InnoDB 1.2.x版本开始，可以通过参数InnoDB_page_size将页的大小设置为4 K、8 K、16 K。若设置完成，则所有表中页的大小都为InnoDB_page_size,不可以对其再次进行修改。除非通过mysqldump导入和导出操作来产生新的库。

InnoDB的数据是按数据页为单位来读写的。也就是说，当需要读一条记录的时候，并不是将这个记录本身从磁盘读出来，而是以页为单位，将其整体读入内存。

而将数据从磁盘读入内存涉及随机IO的访问，是数据库里面成本最高的操作之一，所以为了减少磁盘IO，InnoDB设计了change buffer这个机制。

2. change buffer

在MySQL 5.5之前的版本中，由于只支持缓存insert操作，所以最初叫做insert buffer，只是后来的版本中支持了更多的操作类型缓存，才改叫change buffer，这也是为什么代码中有大量的ibuf前缀开头的函数或变量。

然而使用change buffer需要同时满足两个条件：

(1) 索引是辅助索引

插入聚簇索引一般是顺序的，一般不需要磁盘的随机读取，所以不需要使用change buffer

(2) 索引不是唯一的

辅助索引不能是唯一的，因为在插入缓冲时，数据库并不去查找索引页来判断插入的记录的唯一性。如果去查找肯定又会有离散读取的情况发生，从而导致change buffer失去了意义。

3. change buffer的底层实现

change buffer底层结构是一颗全局的B+树，负责对所有的表空间进行change buffer。

4. merge buffer

从上文可知Change Buffer是一棵B+树。当需要实现插入记录的辅助索引页不在缓冲池中，辅助索引记录首先会插入到这棵B+树中。那么Insert Buffer中的记录何时合并（merge)到真正的辅助索引中呢？

merge操作可能发生在以下几种情况下

辅助索引页被读到缓存中
Change buffer bitmap页追踪到的辅助页已无可用空间
master thread

第一种情况为当辅助索引页被读取到缓冲池中时，例如这在执行正常的SELECT查询操作，这时需要检查Insert Buffer Bitmap页，然后确认该辅助索引页是否有记录存放于Insert Buffer B+树中。若有，则将Insert Buffer B+树中该页的记录插入到该辅助索引页中。对该页多次的记录操作通过几次操作合并到了原有的辅助索引页中，因此性能会有大幅提高。

第二种情况Insert Buffer Bitmap 页用来追踪每个辅助索引页的可用空间，并至少有1/32页的空间。若插入辅助索引记录时检测到插入记录后可用空间会小于1/32页，则会强制进行一个合并操作，即强制读取辅助索引页，将Insert Buffer B+树中该页的记录及待插入的记录插入到辅助索引页中。这就是上述所说的第二种情况。

第三种情况就是在Master Thread线程中每秒或每10秒会进行一次Merge Change Buffer的操作，不同之处在于根据线程的工作状态每次进行merge操作的页的数量不同。

5. change buffer的使用场景

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

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