Innodb buffer pool的flush链表

//

Innodb buffer pool的flush链表

//

《MySQL8.0的redo log优化》一文中，我们介绍了MySQL8.0对redo log 的优化方式，其中有一条是脏页有序加入到flush_list的优化。今天我们来看看flush_list的概念，并解释下这个优化规则。

我们在启动MySQL实例的时候，会给MySQL分配innodb buffer pool的空间，我们先来看innodb buffer pool内存构成如下：

可以看到，buffer pool是由"控制块"和"缓存数据页"组成的，二者一一对应，其中：

1、控制块中的内容主要是缓存数据页的页号、表空间号、数据页所在buffer pool中的地址等一系列信息；

2、单个控制块的大小约为缓存数据页的5%左右；

3、控制块的大小不计入buffer pool的分配空间中，所以，假如你分配了1G的buffer pool，那么实际占用的内存大小可能大于1G，因为MySQL实例启动的时候，需要记入控制块的大小。

了解完buffer pool的内部结构之后，我们来看flush_list的内部结构。先看看flush_list存在的意义吧，当我们修改了缓存数据页的时候，它就和磁盘上的内容不一致了，我们称之为'脏页'，为了让这些修改即时生效，需要将脏页刷回磁盘。那么我们如何确定buffer pool中的哪些数据页是脏页呢？Flush_list就是干这个的。

Innodb存储引擎会将脏页的控制块放入一个flush list的链表中，注意，这里链表中不是真实的缓存数据页，而是数据页对应的控制块。用图来表示就是：

其中，start指向flush链表头节点的地址，end指向flush链表尾节点的地址，控制块节点之间通过pre和next指针相连，组成双向链表。如果再有新的控制块加入到当前列表，则采用"头插法"来插入到flush 列表中。

当某个数据页在内存中第一次被修改的时候，会将它加入到flush链表中，后续如果这个页面再次被改动，那么不再再次插入flush链表。在将控制块加入到flush链表的过程中，会记录该控制块的2条属性：

oldest_modification值

newest_modification值

顾名思义，oldest是指修改该页面的mtr第一次开始时候的lsn号，newest是指最后一次修改该页面的mtr结束时候的lsn号。

这样，你能够理解，在flush链表生成过程中，由于使用'头插法'进行插入，控制块的oldest_modification这个值应该是从右到左有序的，举例如下：

以上，为MySQL5.7版本下的flush链表的基础知识。

来看MySQL8.0引入的优化方案。

MySQL8.0中引入了并行redo 的概念，所以对于redo_log_buffer是乱序写入的，在乱序写入的情况下，很容易出现一种现象，lsn号比较大的数据页先写完redo log buffer，此时需要将其加入到flush list链表，如果将lsn号大的数据页控制块先于lsn小的数据页控制块写入到flush list中，那么flush list中的oldest_modification将不再保持递增顺序，也就无法推进checkpoint点。

针对这种情况，MySQL 8.0通过限制lsn号大于一定阀值L的控制块加入到flush_list做为权衡。假设当前flush_list的lsn最大值为M，那么只有在M值与当前线程lsn相差范围在L以内时，才将脏页写入flush_list。这种策略本质上放宽了之前对于flush_list中对于LSN全局有序，将全局有序限制到L范围内的局部有序。使用这种妥协的方式，先到达flush 链表的lsn较大的控制块不用等待lsn较小的控制块先写入，从而提高事务写入的速度。