Mysql 专栏 – 缓冲池的内部结构(二)

前言

​ 这是 mysql 专栏的第四篇，上一个大节咱们理解了如何通过 flush list 存储所有的脏页数据，这一节咱们来持续介绍缓冲池的内部结构 LRU 链表。

概述

​ 缓冲池的大小是固定的，缓冲池当然不是永远都驻留在缓冲池的，然而闲暇缓冲页不够状况下如何解决呢？本节将会探讨缓冲池重要的淘汰机制：LRU 的淘汰机制，后续会介绍 mysql 的冷热数据拆散个性，最初将给出几个思考题回顾整个内容。

缓存页的刷新机制 – LRU 淘汰缓存页

Buffer pool 中的缓存页不够怎么办？

​ 通过上一节的探讨，当执行器发来了增删改查的申请的时候会从磁盘文件读取对应的数据块到缓冲池当中，之前提到过缓冲池不是有限的，默认状况下最多只有128m，一旦所有的缓存页都被加载就意味着 free list 外部没有闲暇的缓存页，当所有的闲暇缓存页被调配完了，这意味着缓冲池曾经无奈再调配缓冲页了，然而咱们还想把数据页加载到缓存池怎么办？

​ 如果咱们想要加载新的缓存页也非常简略，只有淘汰一些不罕用的缓存页即可。

淘汰那个缓存，淘汰谁？

​ 淘汰缓冲页就是把缓冲池外面的某个缓冲页刷新到磁盘（必须先刷新数据到磁盘）而后把对应的缓存页删除即可。接着再把新的数据页的内容加载到缓冲池即可。那么到底要把那个缓存页刷新到磁盘呢？

缓存命中率

​ 缓存命中率很好了解，假如有两个缓存页，第一个缓存页在 100 次申请中查问和批改了 30 次，意味着这个缓存页的命中率为 30%。并且缓存命中率不错。第二个缓存页则在 100 次内只操作了 1，2 次，这意味着缓存命中率很低，所以不用说，必定是淘汰第二个。

LRU 链表淘汰算法

​ 为了判断哪些缓存页常常被拜访，哪些缓存页很少被拜访。mysql 引入一个新的 LRU 链表，LRU 就是least recently used，也就是起码应用的意思。通过这个 LRU 链表，咱们就能够晓得那个缓存页是起码应用的，当须要一个新的缓存页的时候就能够通过一个 LRU 链表晓得那个缓存页应用频率最低并将其刷新到磁盘文件并且移除。

​ 当某个缓存页被操作的时候，就会找到 LRU 列表对应的节点退出进去，须要淘汰一个缓存页，就找到 LRU 列表的尾部进行淘汰(输出磁盘并且从缓冲池状况，同时 free list 减少一个闲暇的形容信息节点)，因为最初一个节点必定是应用频率最低的。

​ 上面咱们依据之前文章的结构图，补充一个 LRU 链表，最初的结构图内容如下：

简略的 LRU 链表存在哪些问题？

​ 当 Free list 没有可用的闲暇节点的时候，须要从 LRU 链表的尾部刷新一个缓存块到磁盘并且清空这个缓存块把地位让给新的数据块。

然而 mysql 的 LRU 的链表有许多的个性。那么在介绍新个性之前，咱们来看下一般的 LRU 链表会带来哪些问题

简略的 LRU 链表有哪些问题呢？

1. 预读：

​ 首先这样的 LRU 有一个重大的隐患：预读 ，比方当初存在两个闲暇缓存页，加载一个数据页之后，同时会把相邻的数据页页加载到缓存区，正好每一个数据页放入一个闲暇缓存页。 意味着实际上只有一个缓存页被拜访了 ，另一通过预读的机制加载的缓存页，然而这两个都被放到了链表的最后面，最初，预读会造成尾端的缓存页被谬误的删除，然而正确的做法是 删除第二个被预读缓存的缓存页。

​ 接着咱们来看看，到底哪些状况下会触发 MySQL 的预读机制呢?

 (1) 有一个参数是 **innodb_read_ahead_threshold**，他的默认值是 56，意思就是如果程序的拜访了一个区里的多个数据页，拜访的数据页的数量超过了这个阈值，此时就会触发预读机制，把下一个相邻区中的所有数据页都加载到缓存里去。(2) 如果 Buffer Pool 里缓存了一个区里的 13 个间断的数据页，而且这些数据页都是比拟频繁会被拜访的，此时就会间接触发预读机制，把这个区里的其余的数据页都加载到缓存里去
 
 这个预读机制是通过参数 **innodb_random_read_ahead** 来管制的，他 ** 默认是 OFF**，也就是这个规定默认是敞开的

吐槽：预读的机制有点相似机器磁盘的程序拜访操作。

2. 全表扫描

​ 全表扫描置信学过数据库的都晓得这个理念，。从底层来看一个全表扫描的查问可能会把表所有的数据页放到 buffer pool 外面，最终可能会把一整个表的数据页加载到缓存页外面，LRU 的后面一大串页都是全表查问的数据页。这会导致尾部淘汰的缓存页是一些常常用到的缓存页，而留下的都是不怎么应用的数据块，这样缓存的命中率会大大降低，导致整个 mysql 的性能非常差。

冷热数据拆散的 LRU

​ 解决下面的两个问题激素应用冷热拆散的 LRU，冷热拆散的意思是说依照肯定的比例把整个链表分为 热数据和冷数据 ，mysql 当中由 innodb_old_blocks_pct 参数进行管制，默认是 37, 意味着 冷数据占了 37%，热数据占了 63%。

冷热数据如何应用

​ 第一次加载的时候缓存页的数据会放到哪一个地位？略微推敲一下不难得出答案那就是：冷数据的头部。第一次把数据页退出到缓存页默认会放到冷数据的头部。

冷数据什么时候进入热数据

​ 冷数据进入热数据必定是须要肯定的缓存命中率的，所以是依照缓存命中率断定的，是这样么？其实不是的 ， 这样想是错的 ，因为这很难作为一个衡量条件。其实冷热数据是 依照第一次加载缓冲页 1S 之后如果你还是拜访了这个数据页 ，那么这个数据就会降级为热数据也就是放到热数据的头部，另外这个参数是依据innodb_old_blocks_time 这个参数进行判断的，默认设置的参数就 1000（毫秒）也就是 1s。

缓存页不够如何淘汰缓存

​ 冷热拆散之后淘汰缓存页就简略了，间接找到冷数据的尾部缓存页，把这些缓存文件刷到磁盘文件之后能够间接革除，无需放心他们这些数据可能是频繁拜访的数据。

冷热拆散如何解决预读和全表查问问题

​ 当预读和全表查问加载出一大堆的数据之后，会发现他们的数据其实都在 冷数据的头部 的，然而如果 1S 之后仍然频繁拜访的冷数据，则会一直的放到热数据的头部去的，然而一大段读取进去的冷数据，因为只拜访了一次之后就再也没有拜访过了。所以是没有什么关系的。

预读和全表加载的数据，会进入热数据区域么？

​ 如果仅仅是一个全表扫描的查问，此时你必定是在 1s 内就把一大堆缓存页加载进来，而后就拜访了这些缓存页一下后就完事了，通常这些操作 1s 内就完结了。也就是说一个全表查的数据许多的长期数据是会间接放到冷数据页的。然而如果这部分数据在 1S 之后再次被拜访，才会降级为热数据。然而“全表查最好尽量避免，谬误的热数据也是隐患”。

总结：

​ 到当初为止咱们曾经彻底搞定了 LRU 链表的设计机制，刚加载数据的缓存页都是放冷数据区域的头部的，而 1s 过后被拜访了才会放热数据区域的头部，热数据区域的缓存页被拜访了，就会主动放到头部去。这样的话实际上冷数据区域放的都是加载进来的缓存页，最多在 1s 内被拜访过，之后就再也没拜访过的冷数据缓存页！而加载进来之后在 1s 过后还常常被拜访的缓存页都放在了热数据区域里，他们进行了冷热数据的隔离！这样的话在淘汰缓存的时候，肯定是优先淘汰冷数据区域简直不怎么被拜访的缓存页的，最初这种冷热数据拆散的思维是非常值得借鉴的一种设计思维。

思考题：

为什么 MySQL 要设计预读这个机制?

​ 为什么 MySQL 要设计预读这个机制? 他加载一个数据页到缓存里去的时候，为什么要把一些相邻的数据页也加载到缓存里去呢? 这么做的意义在哪里? 是为了应答什么样的一个场景?

​ 为了优化性能引入了预读的机制，程序读取之后可能会呈现后续的程序读取，所以加载前面的数据页也是正当的，然而现实状况下这种预读可能是善意办好事，一旦这些预读的页没有加载进去，就是在捣鬼了。所以这也是为什么 mysql 默认状况下是这个规定敞开的（设计的的确不太好）

为什么要设置 1S 的规定

​ 其实这个规定是针对 全表查问 而设置的，因为全表查问会一次性加载出很多的数据页到缓冲池，然而这些数据在短时间可能被误判为热数据，设置 1S 是因为大部分的全表查问根本都能在 1S 内实现（当然海量数据除外）。

redis 的冷热数据问题

​ 对于这种缓存中同时蕴含冷热数据的场景，如果你是在 Redis 中你的业务零碎放了很多缓存数据，其中也是冷热数据都有的，此时可能会有什么问题？那么针对这样的一个问题，你是否能够思考在你本人的缓存设计中，使用冷热隔离的思维来优化重构呢?

​ 必定是存在问题的，因为假如咱们有 1 亿个商品，而后查问商品不在缓存外面就放到缓存外面，大量不常常拜访的数据会在 redis 外面占用的很多内存然而没有人拜访。所以这时候热数据的预加载就会用上的了，统计哪些商品拜访的次数最多。而后早晨启动定时工作，把热数据放到 redis 外面，第二天加载的时候就会优先加载热数据了。

写在最初

​ 如果感觉有帮忙心愿不忘点个赞给予反对，你的反对和激励是我最大的能源，最初欢送关注集体微信公众号：懒时小窝。

历史文章：

第一篇：Mysql 专栏 – mysql、innodb 存储引擎、binlog 的工作流程 – 掘金 (juejin.cn)

第二篇：Mysql 专栏 – 线上调优与压力测试 – 掘金 (juejin.cn)

上一篇：[Mysql 专栏 – 缓冲池的内部结构（一）– 掘金 (juejin.cn)](