MySQL—缓存_mysql 页缓存

标签：缓存 Buffer mysql young 链表 MySQL Pool

buffer pool缓存什么

InnoDB会把存储的数据划分为若干个页，以页作为磁盘和内存交互的基本单位，一个页默认大小为16KB，MySQL启动时，InnoDB会为buffer pool申请一篇连续的内存空间，然后按照默认的16KB的大小划分出一个个的页，buffer pool中的页就叫做缓存页。

Buffer Pool 除了缓存「索引页」和「数据页」，还包括了 undo 页，插入缓存、自适应哈希索引、锁信息等等。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3kfPU1xv-1691669854944)(C:\Users\hp\AppData\Roaming\Typora\typora-user-images\image-20230810195810532.png)]$

为了更好的管理这些在 Buffer Pool 中的缓存页，InnoDB 为每一个缓存页都创建了一个控制块，控制块信息包括「缓存页的表空间、页号、缓存页地址、链表节点」等等。

控制块也是占有内存空间的，它是放在 Buffer Pool 的最前面，接着才是缓存页，如下图：

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SJ0ZMqA3-1691669854945)(C:\Users\hp\AppData\Roaming\Typora\typora-user-images\image-20230810200153750.png)]$

上图中控制块和缓存页之间灰色部分称为碎片空间。

如何管理Buffer Pool

如何管理空闲页

为了能够快速找到空闲的缓存页，可以使用链表结构，将空闲缓存页的「控制块」作为链表的节点，这个链表称为 Free 链表（空闲链表）。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qfQgWFBG-1691669854945)(C:\Users\hp\AppData\Roaming\Typora\typora-user-images\image-20230810200339489.png)]$

Free 链表上除了有控制块，还有一个头节点，该头节点包含链表的头节点地址，尾节点地址，以及当前链表中节点的数量等信息。

Free 链表节点是一个一个的控制块，而每个控制块包含着对应缓存页的地址，所以相当于 Free 链表节点都对应一个空闲的缓存页。

有了 Free 链表后，每当需要从磁盘中加载一个页到 Buffer Pool 中时，就从 Free链表中取一个空闲的缓存页，并且把该缓存页对应的控制块的信息填上，然后把该缓存页对应的控制块从 Free 链表中移除。

如何管理脏页

buffer pool不仅提高读性能，还要提高写性能。在更新数据的时候，不需要每次都要写入磁盘，而是将buffer pool对应的缓存页标记为脏页，然后由后台线程将脏页写入到磁盘。

那为了能快速知道哪些缓存页是脏的，于是就设计出 Flush 链表，它跟 Free 链表类似的，链表的节点也是控制块，区别在于 Flush 链表的元素都是脏页。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-O7RbqxhN-1691669854946)(C:\Users\hp\AppData\Roaming\Typora\typora-user-images\image-20230810200719929.png)]$

如何提高缓存命中率

使用LRU算法，该算法的思路是，链表头部的节点是最近使用的，而链表末尾的节点是最久没被使用的。那么，当空间不够了，就淘汰最久没被使用的节点，从而腾出空间。

简单的 LRU 算法并没有被 MySQL 使用，因为简单的 LRU 算法无法避免下面这两个问题：

预读失效；
Buffer Pool 污染；

预读失效

先来说说 MySQL 的预读机制。程序是有空间局部性的，靠近当前被访问数据的数据，在未来很大概率会被访问到。所以，MySQL 在加载数据页时，会提前把它相邻的数据页一并加载进来，目的是为了减少磁盘 IO。但是可能这些被提前加载进来的数据页，并没有被访问，相当于这个预读是白做了，这个就是预读失效。

怎么解决预读失效而导致缓存命中率降低的问题？

最好就是让预读的页停留在 Buffer Pool 里的时间要尽可能的短，让真正被访问的页才移动到 LRU 链表的头部，从而保证真正被读取的热数据留在 Buffer Pool 里的时间尽可能长。MySQL 是这样做的，它改进了 LRU 算法，将 LRU 划分了 2 个区域：old 区域和 young 区域。young 区域在 LRU 链表的前半部分，old 区域则是在后半部分，如下图：

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KHKrD20P-1691669854946)(C:\Users\hp\AppData\Roaming\Typora\typora-user-images\image-20230810201102871.png)]$

划分这两个区域后，预读的页就只需要加入到 old 区域的头部，当页被真正访问的时候，才将页插入 young 区域的头部。如果预读的页一直没有被访问，就会从 old 区域移除，这样就不会影响 young 区域中的热点数据。

buffer pool污染

当某一个 SQL 语句扫描了大量的数据时，在 Buffer Pool 空间比较有限的情况下，可能会将 Buffer Pool 里的所有页都替换出去，导致大量热数据被淘汰了，等这些热数据又被再次访问的时候，由于缓存未命中，就会产生大量的磁盘 IO，MySQL 性能就会急剧下降，这个过程被称为 Buffer Pool 污染。

怎么解决出现 Buffer Pool 污染而导致缓存命中率下降的问题？

MySQL 是这样做的，进入到 young 区域条件增加了一个停留在 old 区域的时间判断。具体是这样做的，在对某个处在 old 区域的缓存页进行第一次访问时，就在它对应的控制块中记录下来这个访问时间：

如果后续的访问时间与第一次访问的时间在某个时间间隔内，那么该缓存页就不会被从 old 区域移动到 young 区域的头部；
如果后续的访问时间与第一次访问的时间不在某个时间间隔内，那么该缓存页移动到 young 区域的头部；

这个间隔时间是由 innodb_old_blocks_time 控制的，默认是 1000 ms。也就说，只有同时满足「被访问」与「在 old 区域停留时间超过 1 秒」两个条件，才会被插入到 young 区域头部，这样就解决了 Buffer Pool 污染的问题。另外，MySQL 针对 young 区域其实做了一个优化，为了防止 young 区域节点频繁移动到头部。young 区域前面 1/4 被访问不会移动到链表头部，只有后面的 3/4被访问了才会。

脏页什么时候会被刷入到磁盘

当 redo log 日志满了的情况下，会主动触发脏页刷新到磁盘；
Buffer Pool 空间不足时，需要将一部分数据页淘汰掉，如果淘汰的是脏页，需要先将脏页同步到磁盘；
MySQL 认为空闲时，后台线程会定期将适量的脏页刷入到磁盘；
MySQL 正常关闭之前，会把所有的脏页刷入到磁盘；

标签：缓存,Buffer,mysql,young,链表,MySQL,Pool
From： https://blog.51cto.com/u_17015020/12080306