从0开始带你成为MySQL实战高手17 MySQL是如何基于冷热数据分离的方案，来优化LRU算法的.pdfVIP

图文17MySQL是如何基于冷热数据分离的方案，来优化LRU算法的？手机观看

603人次阅读2020-02-1207:00:00

详情评论

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

如何提问：每篇文章都有评论区，大家可以尽情留言提问，我会逐一答疑

如何加群：购买狸猫技术窝专栏的小伙伴都可以加入狸猫技术交流群，一个非常纯粹的技术交流的地方

具体加群方式，请参见目录菜单下的文档：《MySQL专栏付费用户如何加群》（购买后可见）

1、昨日思考题解答

先给大家解答一下上次给大家布置的思考题，上回我们给大家提了一个问题：为什么MySQL要设计一个预读机制，为

什么有时候要把相邻的一些数据页一次性读入到BufferPool缓存里去？

道理很简单，说白了还不是为了提升性能么。假设你读取了数据页01到缓存页里去，那么好，接下来有可能会接着顺

序读取数据页01相邻的数据页02到缓存页里去，这个时候，是不是可能在读取数据页02的时候要再次发起一次磁盘

IO？

所以为了优化性能，MySQL才设计了预读机制，也就是说如果在一个区内，你顺序读取了好多数据页了，比如数据页

01~数据页56都被你依次顺序读取了，MySQL会判断，你可能接着会继续顺序读取后面的数据页。

那么此时他就干脆提前把后续的一大堆数据页（比如数据页57~数据页72）都读取到BufferPool里去，那么后续你再

读取数据页60的时候，是不是就可以直接从BufferPool里拿到数据了？

当然理想是上述那样，很丰满，但是现实可能很骨感。你预读的一大堆数据页要是占据了LRU链表的前面部分，可能

这些预读的数据页压根儿后续没人会使用，那你这个预读机制就是在捣乱了。

2、基于冷热数据分离的思想设计LRU链表

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

分离的思想。

之前一系列的问题，说白了，不都是因为所有缓存页都混在一个LRU链表里，才导致的么？

所以真正的LRU链表，会被拆分为两个部分，一部分是热数据，一部分是冷数据，这个冷热数据的比例是由

innodb_old_blocks_pct参数控制的，他默认是37，也就是说冷数据占比37%。

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

3、数据页第一次被加载到缓存的时候

好，既然我们知道LRU链表已经按照一定的比例被拆分为了冷热两块区域了，那么接下来就来看看在运行期间，冷热

两个区域是如何使用的。

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

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

页之后，这个缓存页实际上是被放在下图箭头的位置，也就是冷数据区域的链表头部位置。

4、冷数据区域的缓存页什么时候会被放入到热数据区域？

接着我们来思考一个问题，第一次被加载了数据的缓存页，都会不停的移动到冷数据区域的链表头部，如上图所示

那么你要知道，冷数据区域的缓存页肯定是会被使用的，那么冷数据区域的缓存页什么时候会放到热数据区域呢？

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

不行呢？如下图所示。

其实这也是不合理的，如果你刚加载了一个数据页到那个缓存页，他是在冷数据区域的链表头部，然后立马（在1ms

以内）就访问了一下这个缓存页，之后就再也不访问他了呢？难道这种情况你也要把那个缓存页放到热数据区域的头

部吗？

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

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

表头部去。

因为假设你加载了一个数据页到缓存去，然后过了1s之后你还访问了这个缓存页，说明你后续很可能会经常要访问

它，这个时间限制就是1s，因此只有1s后你访问了这个缓存页，他才会给你把缓存页放到热数据区域的链表头部去。

所以我们看下面的图，文字说明做了一点改动，是数据加载到缓存页之后过了1s，你再访问这个缓存页，他就会被放

入