InnoDB的两点特性-插入缓存与双写

介绍下插入缓冲(insert buffer)与两次写(double write).

缓冲池中缓存的数据页组成
包括索引页，数据页，undo页，插入缓冲，自适应哈希索引，锁信息，数据字典信息等。为了确保缓冲池有限空间的最大利用，Innodb通过LRU算法对缓冲池进行管理，也就是最频繁使用的页在LRU列表最前端，而最少使用的页在LRU列表的尾端，当缓冲池不能存放新读取到的页时，将首先释放LRU列表中尾端的页。需要说明下，Innodb并非使用最朴素的LRU算法，而是在LRU列表里加入了midpoint位置，主要是为了应对活跃的热点数据被刷出的问题，midpoint之后中的列表称为old列表，midpoint之前的列表称为new列表，而new列表里都是最为活跃的热点数据。

插入缓冲
为什么需要插入缓冲？

Innodb存储引擎中行记录是按照聚集索引维度顺序存储的，Innodb的表也称为索引表；因为行记录只能按照一个维度进行排序，所以一张表只能有一个聚集索引。

在InnoDB，主键是行唯一标识，通常应用程序中行记录的插入顺序是按照主键递增的顺序进行插入的，因此，插入聚集索引一般是顺序的，不需要磁盘的随机读取。但是对于非聚集索引叶子节点的插入不再是顺序的了，这时就需要离散地访问非聚集索引页(这里再进一步阐明下，非聚集索引的根节点存的是索引列的值，它们是有序的，而根节点下的叶子节存的是主键的值，它们是无序的。又因为行记录是按照聚集索引维度顺序存储的，为了保住插入后的有序性，我们就必须随机离散地访问非聚集索引页以找到叶子节点的主键值)，这里就需要离散地访问非聚集索引页，显然，随机读取是会导致插入操作性能下降。

这样，InnDB设计了Insert Buffer功能：对于非聚集索引的插入或更新操作，不是每一次直接插入到索引页中，而是先判断插入的非聚集索引页是否在缓冲池中，若在，则直接插入；若不在，则先放入到一个Insert Buffer对象中，然后再以一定频率和情况进行Insert Buffer和辅助索引叶子节点的merge操作，这时通常能将多个插入合并到一个操作中，也就是让数据积累到一定量然后批量操作，这就大大提高了对于非聚集索引插入的性能。

不过，Insert Buffer的使用需要同时满足两个条件：

1. 索引是辅助索引
2. 索引不是唯一索引(数据库并不去查找索引页来判断插入的记录是否唯一，如果进行了判断会有离散读的情况发生)

Change Buffer
Change Buffer是对Insert Buffer的升级。如果没有使用Change Buffer，要对不在缓冲池里的非唯一索引页进行修改，那流程是怎样的呢？

1. 先把需要修改的索引页从磁盘加载到缓冲池，一次磁盘随机读操作(随机读写性能要差)；
2. 修改缓冲池中的页，一次内存操作；
3. 写入redo log，一次磁盘顺序写操作（顺序读写性能要高）；

可以看到会出现两磁盘操作(有一次还是随机的),一次内存操作。那如果使用了Change Buffer又是怎样的流程呢？

1. 在写缓冲中记录这个操作(insert的操作而非update操作)，一次内存操作；
2. 写入redo log(为了保证数据不丢失)，一次磁盘顺序写操作；

换句话就是：对页进行了写操作，并不会立刻将磁盘页加载到缓冲池，而仅仅记录缓冲变更(buffer changes)，等未来数据被读取时，会先从磁盘中读取数据页到内存中，然后先执行change buffer的merge操作，保证数据逻辑的正确性。除了查询操作外，系统有后台线程会定期merge，数据库正常关闭(shutdown)的时候，也会进行merge操作。
写缓冲的目的是降低写操作的磁盘IO，提升数据库性能。这里只会出现一次磁盘的顺序操作与一次内存操作，所以性能会很高。
要注意的是，Change Buffer比较适合的业务是写多读少，或者不是写后立刻读取。

Insert Buffer与Change Buffer都是针对的非唯一索引，那这里再展开一唯一索引与非唯一索引的一点区别，也分了读与写两方面。

1. 读时的区别。比如有这样一条SQL：select * from table where k=5;
   k是唯一索引：因为是唯一索引，所以在查找到第一条满足条件的数据后就返回；
   k是非唯一索引：因为是非唯一索引，所以在查找到第一条满足k=5后，还会继续遍历下一条，直到查到的k != 5的时候结束遍历。
   那这两者性能差别大吗？其实并不大，因为有在每次进行查询的时候不仅仅查询当前条件的数据，而是会将整个页的数据查出，再加上缓冲区里的数据页缓冲，所以它们的差别在查询上体现的并不明显。
   但对增删改操作就不一样了。
2. 增删改操作时的区别。
   因为对唯一索引的写操作都需要判断是否违反唯一约束，所以每次更新都需要从内存中查找对应的记录，要是内存里没有需要去磁盘上查询，查到数据后还会马上更新内存里的数据，这样来看，change buffer对唯一索引的写操作就没有意义了；而对于非唯一索引每次只需要从内存里查询，要是没查到只是在内存里将数据记录下来，等后期读取的时候再与磁盘里的数据进行合并，这样change buffer在性能上就起到了很大的作用。
   参考文章：MySQL中的change buffer

Double Write
Insert Buffer对于InnoDB来说是性能上的提升，那Double Write则是数据页可靠性的保证。来看张图：

1. 通过memcpy函数将脏页先复制到内存中的doublewrite buffer。
2. 通过doublewrite buffer分两次，每次1MB顺序写入共享表空间的物理磁盘上，然后调用fsync函数同步磁盘。
3. 完成doublewrite buffer页的写入后，再将doublewrite buffer中的页离散写入各个表空间文件中。

如果第2步出现了问题，也就是doublewrite写入失败，innodb会载入磁盘原始数据和redo日志比较，并重新刷到doublewrite buffer。
如果第3步出了问题，innodb可以从共享表空间中的doublewrite中找到该页的一个副本，将其复制到表空间文件，再应用重做日志。

最后上张图：

对这张图里关于redo与binary log使用两段式提交说明下，因为redolog影响主库的数据，binlog影响从库的数据，所以redolog和binlog必须保持一致才能保证主从数据一致，所以会采用内部XA事务。

参考的文章：
写缓冲(change buffer)，这次彻底懂了！！！
InnoDB关键特性之double write
【mysql】Innodb三大特性之double write
mysql 不会丢失数据吗_MySQL是如何保证数据不会丢的