[深入浅出] 什么是 buffer pool LRU

[深入浅出] 什么是 buffer pool LRU

 

 

new sublist占用5/8的空间        '热端'    经常被访问的数据
midpoint是两者的中间点
old sublist占用3/8的空间          '冷端'    很少被访问的数据

 

1 概述

（本文属于阅读笔记，基本上翻译 MySQL reference 15.5.1 Buffer Pool ）

在MySQL reference介绍InnoDB内存中的数据结构中介绍了缓冲池的改进LRU算法，MySQL使用列表来实现缓冲池。

当缓冲池空间不够时，缓冲池中最近最少被使用的页会被淘汰，新的页会被加入到列表的中间位置。

采用中间插入(midpoint，注意这里虽然说是中间，但是不一定是严格的中间位置，比如默认配置下，该位置从表头计算为列表5/8的位置)

的策略使得列表被分成了如下两个子列表：

在表头保存的是最近被访问的新（"young")页子表。
在表尾是最近没有被访问的旧页子表。
具体的可以参考官网的图如下：

2 实现
MySQL改进的LRU算法将那些被频繁查询的页放在表头部的新页子表中，表尾的旧页子表则放那些较少使用的页，这些页也是淘汰的候选页。

默认配置下，算法操作如下：

3/8的列表划分为尾部的旧页子表，存放那些可以淘汰的旧页。

列表中点(midpoint，注意这里虽然说是中点，但是不一定是严格的中间位置，比如默认配置下，该位置从表头计算为列表5/8的位置)是新页子表和旧页子表的边界。

当 InnoDB 从磁盘读一页数据并放入缓冲池中时，它会将此页插入到列表的中间位置（也就是冷端页子表的头部）。

发生读页一般是因为用户查询数据，或者InnoDB自动触发的read-ahead操作。

'读取旧页子表中的数据会让该页变新（年轻，young），'并将其移动到缓冲池的头部（也就是新页子表的头部）。

如果是因为用户查询读造成该页被读取，则该页会立即被标识为年轻，并直接插入到列表头部。如果该页因为read-ahead被读取，

则首次读取该页并放入缓冲池时不会将该页放入新页列表头部，而是放入列表中点，需要再次读取才能使该页被标识为年轻状态。

（该页可能一直没有被标识为年轻状态直到被淘汰）。

MySQL通过参数innodb_old_blocks_pct来控制旧页子表占整个缓冲池列表的比例，默认为37，也就是上面说的3/8。

'默认的缓冲中的页在第一次被读取时（也就是命中缓存）会被移动到新页子表头部，意味着其会长期待在缓冲池中不会被淘汰。

'这样就会存在一个问题'：一次表扫描（比如使用mysqldump或者没有条件的select查询）可能会将大量数据放入缓存中，并淘汰相应数量的旧数据，

但是可能这些数据只使用一次，后面不再使用；'同样地，因为MySQL自动触发的read-ahead也会在下一次访问该页时被放入新页子表头部。

这些情形会将本应会被频繁使用的页移动到旧页子表中。

所以MySQL采用如下方式避免上面的问题，'新读取的页会放入缓冲池中点，也即默认情况下所有的新读取的页都会被插入到尾部开始的3/8位置处。

'在后面的第一次命中（被访问时）的页会被移动到列表的头部。因此，那些读入缓存但是后面从来不会被访问的页也从不会被放入列表的头部，

也就会在后面被从缓冲池淘汰。

'read-ahead、或者表、索引扫描都会造成类似的缓冲池扰动。'在这些情景下，页通常会被读取（命中）若干次，然后从此不再访问。

为此MySQL提供了配置参数innodb_old_blocks_time用来指定该页在放入缓冲池后第一次读之后一定时间内（时间窗口，单位毫秒,milliseconds）

读取不会被标识为年轻，也就是不会被移动到列表头部。参数innodb_old_blocks_time的默认值是1000，增大这个参数将会造成更多的页会更快的从缓冲池中被淘汰。