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

MySQL——buffer poll

news 文章来源：https://blog.csdn.net/m0_72165281/article/details/144296383 2025/5/9 22:44:14

为什么要有buffer poll？

如果没有buffer poll，每次读取数据的时候都是从磁盘上读的，这样效率是很差的的。所以有了提高效率的方式，就加上了一个缓存——buffer poll

所以，当我们读取数据的时候就有以下的方式

当读取数据的时候，如果buffer poll中有，就直接返回给用户
如果buffer poll中没有，就需要将数据所在的页设置为脏页，然后由后台的线程将脏页读取到磁盘上

buffer poll有多大

在MySQL启动的时候，会向操作系统申请一片内存为buffer poll，默认是128MB。
当然，这个配置是可以通过innodb_buffer_poll_size参数设置

buffer poll中的页

InnoDB会把存储的数据划分为一个个页，每个页的大小都是16KB，而buffer poll中的页就叫做缓存页

什么是脏页、空闲页、干净页

空闲页：buffer poll中没有用到的页
干净页：buffer poll中的页数据和磁盘上的一样
脏页：buffer poll中的页数据和磁盘上的不一样

如何管理空闲页、干净页、脏页？

Free List：只管理空闲页
LRU List：管理干净页和脏页
Flush List：只管理脏页

在这里插入图片描述

Free List：管理空闲的页，当执行查询操作的时候，如果对应的也在buffer poll中就直接返回，如果不在buffer poll中，但Free List不为空，则从磁盘查询对应的数据并且保存到Free List的某个页中，然后将这个页从Free List中移除并放入到LRU List中。
LRU List：管理所有从磁盘读取的页，包含了未被修改和已经修改的页，并根据LRU算法进行维护和淘汰。
Flush List：当LRU List中的页被修改后会被标识为脏页，并把脏⻚加⼊到Flush List 中，在这种情况下，数据库会通过刷盘机制把 Flush List中的脏⻚刷回磁盘

Flush List是一个专门用来管理脏页的列表，而LRU List是用来管理buffer poll中页的可用性。Flush List ⽤来管理要被刷回磁盘的⻚，⼆者互不影响。 Flush List 中的脏⻚在执⾏了刷盘操作后会将空间还给Free List

内存这么多数据页，如何快速找到目标页呢？

第一种方式就是遍历链表，这显然不可取，时间复杂度达到了O（N）
第二种方式就是InnoDB采取的方式，用page Hash的方式，也就是每当磁盘将数据页加载到内存的时候，用数据的页空间ID和页号作为KEY，当前页的地址作为VALUE保存起来，每次查询时通过key来找到对应的value,从而快速找到对应的目标页。时间复杂度是O（1）

脏页什么时候被刷盘呢？

首先我们要知道当修改数据的时候，先修改的是buffer poll所在的页，并标记为脏页，但是此时磁盘还是原来的数据。所以在刷盘前会采用WAL技术，即先写入日志，再写入磁盘。

这样的方式即使MySQL宕机了，也可以通过redo log重新恢复数据。
以下是刷盘时机：

当redo log满了后，会将脏页刷入到磁盘中
buffer poll空间不足时，会淘汰数据页，如果是脏页就会进行刷盘
由后台进程在空闲的时候自动进行刷盘

buffer poll是通过什么方式淘汰数据的？

buffer poll的大小是有限的，难免就有可能buffer poll满了，需要淘汰掉一部分数据。而我们当然希望频繁访问的数据在buffer poll，淘汰掉哪些不经常访问的数据，这就保证了buffer poll可以继续缓存新的数据了。

所以，有了LRU算法。
算法思想：链表头部的数据是最新被访问的，而链表后面的数据是最久未被访问的。那么当空间不足的时候，就要淘汰掉哪些最久未被使用的数据了。

所以当我们访问数据的时候，有两种结果：

如果访问的数据在链表上，就将它放到LRU链表的头部
如果没有在链表上，就需要将页放到链表的头部，并且淘汰掉LRU链表最后的节点。

比如下图，假设LRU链表长度为5，LRU链表从左到右有 1 2 3 4 5的页

在这里插入图片描述
如果访问了3号的页，就需要将3号放到LRU链表的头部

如果访问的8号的页，因为8号页不在buffer poll中，所以需要将8号页放到LRU链表的头部，并且淘汰掉5号页

但是MySQL没有采用这种方式，因为这种方式会带来两个问题

预读失效
buffer poll污染

什么是预读失效？

预读失效：要知道CPU在加载数据的时候，是一块一块存储的，因为相邻的数据可能会在短时间访问到，所以MySQL在加载数据的时候，会将它相邻的数据加载进来，目的就是为了减少磁盘IO。

但是，这些被加载进来的数据是有可能没有被访问的，这就导致了预读失效。

如何解决预读失效问题？

所以为了解决上面的问题，MySQL将LRU算法改进，将LRU链表划分为了2个区域，一个是young区，一个是old区，例如下图
在这里插入图片描述
划分了2个区域后，预读的数据页就会放到old区域，不会放到young区域，只有真正的被访问的使用，会插入到young区域的头部，如果预读的页一直没有被访问就会从old区域中移除。

这样就解决了预读失效的问题，但是还有一个就是buffer poll污染问题没有被解决。

什么是buffer poll污染？

当某个SQL语句需要扫描大量的数据，并且buffer poll内存有限的情况下，可能会将buffer poll里的所有数据全部替换出去，导致大量的热点数据失效了。当再次被访问的时候，就会造成大量的磁盘IO，性能下降，这就是buffer poll污染。

如何解决buffer poll污染的问题？

MySQL为了解决buffer poll污染的问题，将old区域添加了一个时间判断
如果访问的时间在第一次访问的时间间隔内，那么不会将这个数据页从old区域放到young区域，如果不在第一次访问的时间间隔内，就会将该数据页从old渔区放到young区域。这样就解决了buffer poll污染的问题。

参考资料：

https://xiaolincoding.com/mysql/buffer_pool/buffer_pool.html#%E4%B8%BA%E4%BB%80%E4%B9%88%E8%A6%81%E6%9C%89-buffer-pool
https://blog.csdn.net/error044/article/details/131036148?ops_request_misc=%257B%2522request%255Fid%2522%253A%25223ee1266dddf32eb5972cab120fac8f71%2522%252C%2522scm%2522%253A%252220140713.130102334…%2522%257D&request_id=3ee1266dddf32eb5972cab120fac8f71&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2_blogsobaiduend~default-2-131036148-null-null.nonecase&utm_term=buffer%20poll&spm=1018.2226.3001.4450