当前位置: 首页 > news >正文

InnoDB引擎底层解析(二)之InnoDB的Buffer Pool(三)

Buffer Pool 实例

我们上边说过,Buffer Pool 本质是 InnoDB 向操作系统申请的一块连续的内存空间,在多线程环境下,访问 Buffer Pool 中的各种链表都需要加锁处理,在Buffer Pool特别大而且多线程并发访问特别高的情况下,单一的 Buffer Pool 可能会影响请求的处理速度。所以在 Buffer Pool 特别大的时候,我们可以把它们拆分成若干个小的 Buffer Pool ,每个 Buffer Pool 都称为一个实例,它们都是独立的,独立地去申请内存空间,独立的管理各种链表,所以在多线程并发访问时并不会相互影响,从而提高并发处理能力。

我们可以在服务器启动的时候,通过设置innodb_buffer_pool_instances的值来修改Buffer Pool实例的个数,那每个Buffer Pool实例实际占多少内存空间呢?其实使用这个公式算出来的:

innodb_buffer_pool_size/innodb_buffer_pool_instances

也就是每个 Buffer Pool 实例占用的大小等于 buffer pool 缓冲池总共的大小除以实例的个数。

innodb_buffer_pool_chunk_size

在MySQL 5.7.5之前,Buffer Pool 的大小只能在服务器启动时通过配置innodb_buffer_pool_size启动参数来调整大小,在服务器运行过程中是不允许调整该值的。不过 MySQL 在5.7.5以及之后的版本中支持了在服务器运行过程中调整 Buffer Pool 大小的功能,但是有一个问题,就是每次当我们要重新调整 Buffer Pool 大小时,都需要重新向操作系统申请一块连续的内存空间,然后将旧的 Buffer Pool 中的内容复制到这一块新空间,这是极其耗时的。所以 MySQL 决定不再一次性为某 Buffer Pool 实例向操作系统申请一大片连续的内存空间,而是以一个所谓的 chunk 为单位向操作系统申请空间。也就是说一个 Buffer Pool 实例其实是由若干个 chunk 组成的,一个 chunk 就代表一片连续的内存空间,里边儿包含了若干缓存页与其对应的控制块:
在这里插入图片描述
正是因为发明了这个 chunk 的概念,我们在服务器运行期间调整 Buffer Pool 的大小时就是以chunk为单位增加或者删除内存空间,而不需要重新向操作系统申请一片大的内存,然后进行缓存页的复制。这个所谓的 chunk 的大小是我们在启动操作MySQL服务器时通过innodb_buffer_pool_chunk_size启动参数指定的,它的默认值是134217728,也就是128M。不过需要注意的是,innodb_buffer_pool_chunk_size的值只能在服务器启动时指定,在服务器运行过程中是不可以修改的。

show variables like 'innodb_buffer_pool_chunk_size';

在这里插入图片描述
Buffer Pool 的缓存页除了用来缓存磁盘上的页面以外,还可以存储锁信息、自适应哈希索引等信息。

查看Buffer Pool的状态信息

MySQL 给我们提供了 SHOW ENGINE INNODB STATUS 语句来查看关于 InnoDB 存储引擎运行过程中的一些状态信息,其中就包括 Buffer Pool 的一些信息,我们看一下(为了突出重点,我们只把输出中关于 Buffer Pool 的部分提取了出来):

show engine innodb status\G

这里边的每个值都代表什么意思如下,知道即可:
在这里插入图片描述

  • Total large memory allocated: 代表 Buffer Pool 向操作系统申请的连续内存空间大小,包括全部控制块、缓存页、以及碎片的大小。
  • Dictionary memory allocated: 为数据字典信息分配的内存空间大小,注意这个内存空间和Buffer Pool没啥关系,不包括在Total memory allocated中。
  • Buffer pool size: 代表该Buffer Pool可以容纳多少缓存页,注意,单位是页
  • Free buffers: 代表当前Buffer Pool还有多少空闲缓存页,也就是free链表中还有多少个节点。
  • Database pages: 代表LRU链表中的页的数量,包含young和old两个区域的节点数量。
  • Old database pages: 代表LRU链表old区域的节点数量。
  • Modified db pages:代表脏页数量,也就是flush链表中节点的数量。
  • Pending reads:正在等待从磁盘上加载到Buffer Pool中的页面数量。
  • Pending writes
    • LRU:即将从LRU链表中刷新到磁盘中的页面数量。
    • flush list:即将从flush链表中刷新到磁盘中的页面数量。
    • single page:即将以单个页面的形式刷新到磁盘中的页面数量。
  • Pages made young:代表LRU链表中曾经从old区域移动到young区域头部的节点数量
  • Page made not young :在将innodb_old_blocks_time设置的值大于0时,首次访问或者后续访问某个处在old区域的节点时由于不符合时间间隔的限制而不能将其移动到young区域头部时,Page made not young的值会加1。
  • **youngs/s:**代表每秒从old区域被移动到young区域头部的节点数量。
  • **non-youngs/s:**代表每秒由于不满足时间限制而不能从old区域移动到young区域头部的节点数量。
  • Pages read、created、written:代表读取,创建,写入了多少页。后边跟着读取、创建、写入的速率。
  • **Buffer pool hit rate:**表示在过去某段时间,平均访问1000次页面,有多少次该页面已经被缓存到Buffer Pool了。
  • young-making rate:表示在过去某段时间,平均访问1000次页面,有多少次访问使页面移动到young区域的头部了。
  • not(young-making rate):表示在过去某段时间,平均访问1000次页面,有多少次访问没有使页面移动到young区域的头部。
  • LRU len:代表LRU链表中节点的数量。
  • unzip_LRU:代表unzip_LRU链表中节点的数量。
  • I/O sum:最近50s读取磁盘页的总数。
  • I/O cur:现在正在读取的磁盘页数量。
  • I/O unzip sum:最近50s解压的页面数量。
  • I/O unzip cur:正在解压的页面数量。

InnoDB的内存结构总结

InnoDB的内存结构和磁盘存储结构图总结如下:
在这里插入图片描述
其中的 Insert/Change Buffer 主要是用于对二级索引的写入优化,Undo空间则是undo日志一般放在系统表空间,但是通过参数配置后,也可以用独立表空间存放,所以用虚线表示。

相关文章:

  • Linux驱动:基本环境准备
  • 【免费使用】剪Y专业版 8.1/CapCut 视频编辑处理,素材和滤镜
  • 基于CSP模型实现的游戏排行榜
  • AI大模型核心基础:向量与张量原理及实践应用指南
  • ARM笔记-嵌入式系统基础
  • 基于python的百度迁徙迁入、迁出数据分析(城市版)
  • 将ft2232外部的EEPROM中的信息读出来的方法,方便写入到下一个eeprom里面去;
  • Firecrawl MCP Server 深度使用指南
  • Linux系统基础——是什么、适用在哪里、如何选
  • NSSCTF-[羊城杯 2023]程序猿Quby
  • 建筑机械员(建筑施工机械管理人员)考试练习题
  • unordered_set与unordered_map实现详解剖析
  • 通过设备节点获取已注册的 i2c client
  • Vue3 Composition API: 企业级应用最佳实践方案
  • 什么是电离层闪烁
  • YOLOv8损失函数代码详解(示例展示数据变换过程)
  • 模型常见损失函数、softmax、交叉熵损失函数
  • python中的numpy(数组)
  • 2025.5个人感悟
  • leetcode hot100刷题日记——16.全排列
  • 阿里云搭建企业网站/开创集团与百度
  • 石岩做网站哪家好/中国万网域名注册官网
  • 网站个别页面做seo/十大场景营销案例
  • 网站的建设服务/seozou是什么意思
  • 类模板模板下载网站有哪些/企业网址
  • 寿光网站制作/小程序开发哪家好