Innodb Buffer Pool缓存机制(三)Innodb Buffer Pool内部组成

一、控制块+缓存页

  Buffer Pool中默认的缓存页大小和在磁盘上默认的页大小是一样的,都是16KB。为了更好的管理这些在Buffer Pool中的缓存页,InnoDB为每一个缓存页都创建了一些所谓的控制信息,这些控制信息包括该页所属的表空间编号、页号、缓存页在Buffer Pool中的地址、链表节点信息、一些锁信息以及LSN信息,当然还有一些别的控制信息。

  每个缓存页对应的控制信息占用的内存大小是相同的,称为控制块。控制块和缓存页是一一对应的,它们都被存放到Buffer Pool 中,其中控制块被存放到Buffer Pool的前边,缓存页被存放到Buffer Pool后边,所以整个Buffer Pool对应的内存空间看起来就是这样的:

注:每个控制块大约占用缓存页大小的5%,而设置的innodb_buffer_pool_size并不包含这部分控制块占用的内存空间大小,也就是说InnoDB在为Buffer Pool向操作系统申请连续的内存空间时,这片连续的内存空间一般会比innodb_buffer_pool_size的值大5%左右。

二、Free链表管理

MySQL服务在刚启动的时候,需要完成对Buffer Pool的初始化,也就是向操作系统申请Buffer Pool的存储空间,然后它们划分为若干对控制块和缓存页

但此时还没有使用,所以Buffer Pool中还没有真实的页数据,随着程序运行,就会慢慢有磁盘页数据被缓存在Buffer Pool中。

对于InnoDB来说,将磁盘页读取到Buffer Pool中有几个关键问题,即哪些缓存页是空闲,哪些缓存页已经被使用了。

缓存页对应的控制块就起了大作用,可以把所有空闲的缓存页对应的控制块作为一个节点放到一个链表中,这个链表也可以被称作free链表,或者说空闲链表。

刚完成初始化的Buffer Pool中所有的缓存页都是空闲的,所以每一个缓存页对应的控制块都会被加入到free链表中,free链表的效果图就是这样的:

有了这个free链表之后,每当需要从磁盘中加载一个页到Buffer Pool中时,就从free链表中取一个空闲的缓存页,并且把该缓存页对应的控制块的信息填上(就是该页所在的表空间、页号之类的信息),然后把该缓存页对应的free链表节点从链表中移除,表示该缓存页已经被使用了。

三、缓存页的哈希处理

当访问某个页的数据时,如何知道该页已经在Buffer Pool中了呢

InnoDB根据表空间号 + 页号来定位一个页,所以可以用表空间号 + 页号作为key,缓存页作为value创建一个哈希表,在需要访问某个页的数据时,先从哈希表中根据表空间号 + 页号看看有没有对应的缓存页,如果有,直接使用该缓存页就好,如果没有,那就从free链表中选一个空闲的缓存页,然后把磁盘中对应的页加载到该缓存页的位置。

四、flush链表管理

如果修改了Buffer Pool中某个缓存页的数据,那它就和磁盘上的页不一致了,这样的缓存页也被称为脏页(Dirty Page)

内存的数据修改后,要保证磁盘上的数据也同步进行修改,最简单的做法就是每发生一次修改就立即同步到磁盘上对应的页上,但是频繁的往磁盘中写数据会严重的影响程序的性能。所以每次修改缓存页后,我们并不着急立即把修改同步到磁盘上,而是在未来的某个时间点进行同步。

在同步内存数据到磁盘中时,需要知道Buffer Pool中哪些缓存页的数据发生了变化,所以同样需要一个存储脏页的链表,凡是修改过的缓存页对应的控制块都会作为一个节点加入到一个链表中,因为这个链表节点对应的缓存页都是需要被刷新到磁盘上的,所以也叫flush链表。链表的构造和free链表差不多。

五、LRU链表管理

Buffer Pool的大小是有限的,free链表总归有用完的时候,这个时候就涉及到缓存页淘汰的问题了,把旧的缓存页移除,然后把新的缓存页放进来。

Buffer Pool的初衷就是为了减少磁盘IO的次数,缓存命中率越高越好

所以,Buffer Pool的淘汰策略使用LRU算法,淘汰最近最少使用的缓存页,留下最近使用比较频繁的缓存页。

InnoDB为了知道哪些缓存页是最近使用的,就需要再创建一个链表,该链表使用LRU算法来淘汰缓存页,所以称为LRU链表,当访问某个页时,它的工作过程如下:

  • 如果该页不在Buffer Pool中,就把该页从磁盘加载到Buffer Pool中的缓存页时,然后把该缓存页对应的控制块作为节点塞到LRU链表的头部;
  • 如果该页已经缓存在Buffer Pool中,则直接把该页对应的控制块移动到LRU链表的头部;

只要我们使用到某个缓存页,就把该缓存页调整到LRU链表的头部,这样LRU链表尾部就是最近最少使用的缓存页。所以当Buffer Pool中的空闲缓存页使用完时,到LRU链表的尾部找些缓存页淘汰就可以了。

这种简单的LRU链表其实是有一些问题,主要与InnoDB自生的一些特性和SQL语句有关。

mysql当然不会用这样的LRU链表,它对了一下优化,详情请见下一章。

相关推荐
云贝贝贝2 小时前
腾讯云 TDSQL(MySQL 版)运维高频 6 坑:代理路由、读写分离、分片键、监控、PITR
运维·mysql·腾讯云
山岚的运维笔记6 小时前
mysql 专业笔记 -- 第 8 章:使用变量
运维·数据库·笔记·后端·学习·mysql·dba
JavaPub-rodert11 小时前
Redis 和 MySQL 如何保证数据一致性?从业务方案到底层原理完整讲解
数据库·redis·mysql
笑梦无境12 小时前
mysql的安装及配置(3)
数据库·mysql·adb
OH_TPC12 小时前
【鸿蒙优选三方库】@react-native-ohos/react-native-fast-image:高性能图片加载与缓存组件
缓存·华为·harmonyos·鸿蒙
liangshanbo121512 小时前
手写 Event Emitter(事件发射器)
缓存
Gent_倪12 小时前
MySQL分库、分表、分区详解
数据库·mysql
Wang's Blog13 小时前
Vibe Coding一人即团队系列54:云服务器 Node.js 与 MySQL 9 环境搭建及配置指南
服务器·人工智能·mysql·node.js
数智启示录13 小时前
Apache Kafka Consumer 扩到 40 个仍不提速:Partition 上限锁死有效并行度 【Kafka合集】
数据库·经验分享·分布式·缓存·面试·kafka·apache
数智启示录13 小时前
Apache Kafka 幂等 Producer 的边界:Exactly-Once 到了 MySQL 为什么失效 【Kafka合集】
数据库·经验分享·分布式·mysql·面试·kafka·apache