17 MySQL是如何基于冷热数据分离的方案，来优化LRU算法的？

gong_yz2023/2/27大约 4 分钟

1、昨日思考题解答

思考上一个问题，为什么MySQL要设计一个预读机制，为什么有时候要把相邻的一些数据页一次性读入到Buffer Pool缓存里去？

说白了还不是为了提升性能么。假设你读取了数据页01到缓存页里去，那么好，接下来有可能会接着顺序读取数据页01相邻的数据页02到缓存页里去，这个时候，是不是可能在读取数据页02的时候要再次发起一次磁盘IO？

所以为了优化性能，MySQL才设计了预读机制，也就是说如果在一个区内，你顺序读取了好多数据页了，比如数据页01~数据页56都被你依次顺序读取了，MySQL会判断，你可能接着会继续顺序读取后面的数据页。

那么此时他就干脆提前把后续的一大堆数据页（比如数据页57~数据页72）都读取到Buffer Pool里去，那么后续你再读取数据页60的时候，是不是就可以直接从Buffer Pool里拿到数据了？

但是现实可能很骨感。你预读的一大堆数据页要是占据了LRU链表的前面部分，可能这些预读的数据页压根儿后续没人会使用，那你这个预读机制就是在捣乱了。

为了解决上一讲我们说的简单的LRU链表的问题，真正MySQL在设计LRU链表的时候，采取的实际上是冷热数据分离的思想。

之前一系列的问题都是因为所有缓存页都混在一个LRU链表里才导致的。

所以真正的LRU链表，会被拆分为两个部分，一部分是热数据，一部分是冷数据，这个冷热数据的比例是由 innodb_old_blocks_pct 参数控制的，他默认是37，也就是说冷数据占比37%。

这个时候，LRU链表实际上看起来是下面这样子的。

接下来就来看看在运行期间，冷热两个区域是如何使用的。

首先数据页第一次被加载到缓存的时候，这个时候缓存页会被放在LRU链表的哪个位置呢？

缓存页会被放在冷数据区域的链表头部，我们看下面的图，也就是第一次把一个数据页加载到缓存页之后，这个缓存页实际上是被放在下图箭头的位置，也就是冷数据区域的链表头部位置。

冷数据区域的缓存页什么时候会放到热数据区域呢？

实际上肯定很多人会想，只要对冷数据区域的缓存页进行了一次访问，就立马把这个缓存页放到热数据区域的头部行不行呢？如下图所示。

其实这也是不合理的，如果你刚加载了一个数据页到那个缓存页，他是在冷数据区域的链表头部，然后立马（在1ms以内）就访问了一下这个缓存页，之后就再也不访问他了呢？难道这种情况你也要把那个缓存页放到热数据区域的头部吗？

所以MySQL设定了一个规则，他设计了一个 innodb_old_blocks_time 参数，默认值1000，也就是1000毫秒

也就是说，必须是一个数据页被加载到缓存页之后，在1s之后，你访问这个缓存页，他才会被挪动到热数据区域的链表头部去。

因为假设你加载了一个数据页到缓存去，然后过了1s之后你还访问了这个缓存页，说明你后续很可能会经常要访问它，这个时间限制就是1s，因此只有1s后你访问了这个缓存页，他才会给你把缓存页放到热数据区域的链表头部去。

所以我们看下面的图，文字说明做了一点改动，是数据加载到缓存页之后过了1s，你再访问这个缓存页，他就会被放入热数据区域的链表头部，如果是你数据刚加载到缓存页，在1s内你就访问缓存页，此时他是不会把这个缓存页放入热数据区域的头部的。

基于这套冷热数据隔离的方案，LRU链表的冷数据区域放的都是什么样的缓存页？