InnoDB Buffer Pool 缓冲池详解

最新推荐文章于 2024-05-27 14:18:53 发布

置顶涛声依旧叭

最新推荐文章于 2024-05-27 14:18:53 发布

阅读量3.6k

点赞数 5

分类专栏：跟我一起盘MySQL 文章标签：数据库 java mysql buffer pool innodb

本文链接：https://blog.csdn.net/rongtaoup/article/details/127558098

版权

跟我一起盘MySQL 专栏收录该内容

10 篇文章 61 订阅

订阅专栏

本文大纲

在这里插入图片描述

Buffer Pool 基础

缓冲池 Buffer Pool 的作用

InnoDB 存储引擎是基于磁盘存储的。以页为单位存储数据。我们进行的增删改查操作本质上都是在操作数据页（包括读页、写页、创建新页）。由于CPU速度和磁盘速度之间的鸿沟，基于磁盘的数据库通常使用缓冲池来提高数据库的整体性能。

Buffer Pool 就是把磁盘上的页，缓存到内存中，用于降低与磁盘直接进行IO的成本。

InnoDB 引擎在处理客户端请求时，当需要访问某个页的数据时，就会把完整的页的数据全部加载到内存中。之后就可以对页进行读写访问了。操作完页之后并不会立即释放掉其内存空间，而是将其缓存起来，将来有请求再次访问该页数据时，就可以省去磁盘IO的开销了。

在这里插入图片描述

Buffer Pool 缓存什么？

MySQL启动时， InnoDB 引擎向操作系统申请一块连续的内存空间，然后按照页的大小（默认16KB）划分出一个个空页，当磁盘上的页缓存到内存的 Buffer Pool 中会对空页进行填充。

缓冲池中的数据页类型有：数据页、索引页、插入缓冲（insert buffer）、自适应哈希索引、锁信息、数据字典信息等。数据页和索引页是缓冲池中的主要内容。

在这里插入图片描述

查看设置缓冲池大小

InnoDB 引擎通过 innodb_buffer_pool_size 变量查看缓冲池的大小。一般建议设置成可用物理内存的 60%~80%

mysql > show variables like 'innodb_buffer_pool_size'

在这里插入图片描述

通过 set global innodb_buffer_pool_size 修改缓冲池大小。

缓冲池的预读特性

缓冲池的作用就是提升IO效率，而在读取数据时存在“局部性原理”。也就是说我们使用了一些数据，大概率还会使用它周围的一些数据。

当数据页从磁盘加载到 Buffer Pool 中时，会把相邻的数据页也加载到 Buffer Pool 中，使用预读机制提前加载出来，可以减少未来可能的磁盘IO。

管理 Buffer Pool

数据页管理

Buffer Pool 中的页有以下几种状态：

1、空闲页：通过空闲页链表（Free List）管理。

2、已被使用的正常页：通过LRU链表（LRU List）管理。

3、已被使用的脏页：通过LRU链表和脏页链表（Flush List）管理。

脏页（dirty page）：指缓冲池中被修改过的页，与磁盘上的数据页不一致。

Buffer Pool 中的空闲页通过空闲页链表管理，每当从磁盘中读取数据页缓存到Buffer Pool中时，从空闲页链表取一个空闲页使用，并从空闲链表中移除。

当需要将脏页刷盘时，遍历脏页链表，将脏页写入磁盘。

已被使用的正常页通过LRU链表管理，其中LRU链表上也有脏页。

在这里插入图片描述

缓冲池的大小是有限的，比如磁盘有50G，内存8G，而缓冲池只有1G。是无法将磁盘的数据全部放在缓冲池里，需要根据优先级来缓存数据，会优先对使用频次高的热数据进行加载。

你可以在 show engine innodb status 结果中，查看一个系统当前的 BP 命中率。一般情况下，一个稳定服务的线上系统，要保证响应时间符合要求的话，内存命中率要在 99% 以上。

执行 show engine innodb status ，可以看到Buffer pool hit rate字样，显示的就是当前的命中率。比如这个命中率，就是 99.0%。

在这里插入图片描述

基础 LRU 算法

InnoDB 内存管理用的是最近最少使用 (Least Recently Used, LRU) 算法，这个算法的核心就是淘汰最久未使用的数据。InnoDB 管理 Buffer Pool 的 LRU 算法，是用链表来实现的。

LRU链表：

链表头节点存储最近使用的数据，链表尾部节点存储最久未被使用的数据。淘汰时删除链表尾部节点。

在这里插入图片描述

LRU链表的基本操作：

1、state1状态：P1是最近使用的页，Pm是最久未被使用的页。

2、state2状态：当有读请求访问P3页，P3移动到head节点。

3、state3状态：假设Px页不在buffer pool中，而此时内存已经满了，需要先淘汰掉LRU尾结点（最久未被使用的Pm），再将Px放到head节点。

InnoDB 改进后的 LRU 算法

实际上， InnoDB 引擎对LRU算法做了改进。为什么没有直接使用基础LRU算法呢？

试想一下，如果要对一个很大的表做全表扫描，这个表是一个冷数据表（平时没有业务访问它）。如果使用基础的LRU算法，会把Buffer Pool里的数据全部淘汰掉，存储的都是冷数据表的数据页。

这会导致Buffer Pool的内存命中率急剧下降，并且由于内存中没有热点数据，导致大量磁盘IO增加磁盘压力，SQL语句响应变慢。

InnoDB 引擎改进后的LRU算法如下：

InnoDB 将LRU链表按照5:3的比例分成了young区域和old区域。链表头部的5/8是young区，链表尾部的3/8区域是old区域。

old区域占整个LRU链表的长度由参数innodb_old_blocks_pc控制

在这里插入图片描述

1、当要访问P3页时，P3在young区直接移动到链表头结点。（state1 -> state2）

2、当要访问不存在Buffer Pool上的页时（Px），删除old区域尾结点Pm，但是与基础LRU算法不同的是，Px插入在old区域的“头结点”。

3、处于old区域的数据页，每次被访问到时，都需要做下面这个判断：

若这个数据页在LRU链表的时间超过了1秒，说明它是热点数据，将其移动到LRU链表young区域的头结点。
若这个数据页再LRU链表的时间小于1秒，则不做任何处理。
1秒这个时间是由参数innodb_old_blocks_time控制的，默认是1000ms

以上， InnoDB 改进后的LRU算法，在做全表扫描时，过程如下：

1、扫描过程中，需要新插入的数据页，都放到old区域

2、数据页中存储的是多条记录，因此这个数据页会被多次访问到，但由于是顺序扫描，这个数据页第一次被访问和最后一次被访问的时间间隔不会超过 1 秒，因此这个数据页还是会被保留在 old 区域；

3、继续扫描后续的数据页，之前的这个数据页之后也不会再被访问到，它不会移动到young区域的链表头部，很快就会被淘汰出去。

改进后的LRU算法，即使再做大表全表扫描时，对LRU链表的young区域也没有影响，保证了Buffer Pool的命中率。

引申问题：全表扫描对server的影响

问题：如果对一个200G的做全表扫描，会不会把mysql服务器内存用光？

实际上mysql server并不会保存完整的结果集。MySQL是“边读边发”的。server读取的数据会写到net_buffer 内存块中，net_buffer的默认大小是16KB，内存块写满了就会将结果发送给客户端，客户端成功接收后，就会清空net_buffer，继续读取、发送数据。

多个Buffer Pool实例

Buffer pool 本质是 InnoDB 向操作系统申请一块连续的内存空间。

多线程并发情况访问，单一的Buffer pool 会影响请求的处理速度。因为涉及到竞争问题。所以在Buffer pool 很大的时候，将其拆分成若干个小的Buffer pool ，每个Buffer pool 都是一个实例，独立申请内存空间，独立管理数据。多线程并发访问时，不会互相影响，提高并发处理能力。

通过 Innodb_buffer_pool_instances 参数修改实例个数。通过innodb_buffer_pool_size参数查看缓冲池的大小。