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

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

1、昨日思考题解答

先给大家解答一下上次给大家布置的思考题，上回我们给大家提了一个问题：为什么MySQL要设计一个预读机制，为什么有时候要把相邻的一些数据页一次性读入到Buffer Pool缓存里去？

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

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

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

当然理想是上述那样，很丰满，但是现实可能很骨感。你预读的一大堆数据页要是占据了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，你再访问这个缓存页，他就会被放入热数据区域的链表头部，如果是你数据刚加载到缓存页，在1s内你就访问缓存页，此时他是不会把这个缓存页放入热数据区域的头部的。

      

             

5、思考题

今天给大家留一个思考题，大家思考一下，现在我们已经知道了，数据页第一次被加载到缓存页之后，这个缓存页是放在LRU链表的冷数据区域的头部的，然后必须是1s过后访问换个缓存页，他才会被移动到热数据区域的链表头部。

好，那么基于这套冷热数据隔离的方案，LRU链表的冷数据区域放的都是什么样的缓存页？这个问题有点像脑筋急转弯一样，大家脑子一转，就能思考出来了。

大家可以好好思考一下，把你的答案发到评论区里跟其他同学交流。

End

专栏版权归公众号儒猿技术窝所有

未经许可不得传播，如有侵权将追究法律责任