数据库缓冲池(buffer pool)详解,你还不会,那我就莫法啦。

2021年11月20日 阅读数:3
这篇文章主要向大家介绍数据库缓冲池(buffer pool)详解,你还不会,那我就莫法啦。,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

应用系统分层架构,为了加速数据访问,会把最常访问的数据,放在缓存(cache)里,避免每次都去访问数据库。面试

操做系统,会有缓冲池(buffer pool)机制,避免每次访问磁盘,以加速数据的访问。算法

MySQL做为一个存储系统,一样具备缓冲池(buffer pool)机制,以免每次查询数据都进行磁盘IO。数据库

今天,和你们聊一聊InnoDB的缓冲池。缓存

InnoDB的缓冲池缓存什么?有什么用?架构

缓存表数据与索引数据,把磁盘上的数据加载到缓冲池,避免每次访问都进行磁性能

盘IO,起到加速访问的做用。测试

速度快,那为啥不把全部数据都放到缓冲池里?优化

凡事都具有两面性,抛开数据易失性不说,访问快速的反面是存储容量小:操作系统

A .缓存访问快,但容量小,数据库存储了200G数据,缓存容量可能只有64G;设计

B.内存访问快,但容量小,买一台笔记本磁盘有2T,内存可能只有16G;

所以,只能把“最热”的数据放到“最近”的地方,以“最大限度”的下降磁盘访问。

如何管理与淘汰缓冲池,使得性能最大化呢?在介绍具体细节以前,先介绍下“预读”的概念。

在这里插入图片描述
A.什么是预读?

磁盘读写,并非按需读取,而是按页读取,一次至少读一页数据(通常是4K),若是将来要读取的数据就在页中,就可以省去后续的磁盘IO,提升效率。

B.预读为何有效?

数据访问,一般都遵循“集中读写”的原则,使用一些数据,大几率会使用附近的数据,这就是所谓的“局部性原理”,它代表提早加载是有效的,确实可以减小磁盘IO。

按页(4K)读取,和InnoDB的缓冲池设计有啥关系?

(1)磁盘访问按页读取可以提升性能,因此缓冲池通常也是按页缓存数据;

(2)预读机制启示了咱们,能把一些“可能要访问”的页提早加入缓冲池,避免将来的磁盘IO操做;

InnoDB是以什么算法,来管理这些缓冲页呢?

最容易想到的,就是LRU(Least recently used)。

画外音:memcache,OS都会用LRU来进行页置换管理,但MySQL的玩法并不同。

传统的LRU是如何进行缓冲页管理?

最多见的玩法是,把入缓冲池的页放到LRU的头部,做为最近访问的元素,从而最晚被淘汰。这里又分两种状况:

A.页已经在缓冲池里,那就只作“移至”LRU头部的动做,而没有页被淘汰;

B.页不在缓冲池里,除了作“放入”LRU头部的动做,还要作“淘汰”LRU尾部页的动做;

在这里插入图片描述
如上图,假如管理缓冲池的LRU长度为10,缓冲了页号为1,3,5…,40,7的页。

假如,接下来要访问的数据在页号为4的页中:
在这里插入图片描述
A.页号为4的页,原本就在缓冲池里;

B.把页号为4的页,放到LRU的头部便可,没有页被淘汰;

画外音:为了减小数据移动,LRU通常用链表实现。

假如,再接下来要访问的数据在页号为50的页中:

在这里插入图片描述
A.页号为50的页,原来不在缓冲池里;

B.把页号为50的页,放到LRU头部,同时淘汰尾部页号为7的页;

传统的LRU缓冲池算法十分直观,OS,memcache等不少软件都在用,MySQL为啥这么矫情,不能直接用呢?

这里有两个问题:

1.预读失效;

2.缓冲池污染;

C.什么是预读失效?

因为预读(Read-Ahead),提早把页放入了缓冲池,但最终MySQL并无从页中读取数据,称为预读失效。

D.如何对预读失效进行优化?

要优化预读失效,思路是:

(1)让预读失败的页,停留在缓冲池LRU里的时间尽量短;

(2)让真正被读取的页,才挪到缓冲池LRU的头部;

以保证,真正被读取的热数据留在缓冲池里的时间尽量长。

具体方法是:

(1)将LRU分为两个部分:

新生代(new sublist)

老生代(old sublist)

(2)新老生代收尾相连,即:新生代的尾(tail)链接着老生代的头(head);

(3)新页(例如被预读的页)加入缓冲池时,只加入到老生代头部:

若是数据真正被读取(预读成功),才会加入到新生代的头部

若是数据没有被读取,则会比新生代里的“热数据页”更早被淘汰出缓冲池

在这里插入图片描述
举个例子,整个缓冲池LRU如上图:

(1)整个LRU长度是10;

(2)前70%是新生代;

(3)后30%是老生代;

(4)新老生代首尾相连;
在这里插入图片描述
假若有一个页号为50的新页被预读加入缓冲池:

(1)50只会从老生代头部插入,老生代尾部(也是总体尾部)的页会被淘汰掉;

(2)假设50这一页不会被真正读取,即预读失败,它将比新生代的数据更早淘汰出缓冲池;

在这里插入图片描述
假如50这一页马上被读取到,例如SQL访问了页内的行row数据:

(1)它会被马上加入到新生代的头部;

(2)新生代的页会被挤到老生代,此时并不会有页面被真正淘汰;

改进版缓冲池LRU可以很好的解决“预读失败”的问题。

画外音:但也不要因噎废食,由于惧怕预读失败而取消预读策略,大部分状况下,局部性原理是成立的,预读是有效的。

新老生代改进版LRU仍然解决不了缓冲池污染的问题。

什么是MySQL缓冲池污染?

当某一个SQL语句,要批量扫描大量数据时,可能致使把缓冲池的全部页都替换出去,致使大量热数据被换出,MySQL性能急剧降低,这种状况叫缓冲池污染。

例如,有一个数据量较大的用户表,当执行:

select * from user where name like “%shenjian%”;

虽然结果集可能只有少许数据,但这类like不能命中索引,必须全表扫描,就须要访问大量的页:

(1)把页加到缓冲池(插入老生代头部);

(2)从页里读出相关的row(插入新生代头部);

(3)row里的name字段和字符串shenjian进行比较,若是符合条件,加入到结果集中;

(4)…直到扫描完全部页中的全部row…

如此一来,全部的数据页都会被加载到新生代的头部,但只会访问一次,真正的热数据被大量换出。

怎么这类扫码大量数据致使的缓冲池污染问题呢?

MySQL缓冲池加入了一个“老生代停留时间窗口”的机制:

(1)假设T=老生代停留时间窗口;

(2)插入老生代头部的页,即便马上被访问,并不会马上放入新生代头部;

(3)只有知足“被访问”而且“在老生代停留时间”大于T,才会被放入新生代头部;
在这里插入图片描述

继续举例,假如批量数据扫描,有51,52,53,54,55等五个页面将要依次被访问。

!在这里插入图片描述

若是没有“老生代停留时间窗口”的策略,这些批量被访问的页面,会换出大量热数据。
在这里插入图片描述

加入“老生代停留时间窗口”策略后,短期内被大量加载的页,并不会马上插入新生代头部,而是优先淘汰那些,短时间内仅仅访问了一次的页。

在这里插入图片描述

而只有在老生代呆的时间足够久,停留时间大于T,才会被插入新生代头部。

上述原理,对应InnoDB里哪些参数?

有三个比较重要的参数。
在这里插入图片描述

参数:innodb_buffer_pool_size

介绍:配置缓冲池的大小,在内存容许的状况下,DBA每每会建议调大这个参数,越多数据和索引放到内存里,数据库的性能会越好。

参数:innodb_old_blocks_pct

介绍:老生代占整个LRU链长度的比例,默认是37,即整个LRU中新生代与老生代长度比例是63:37。

画外音:若是把这个参数设为100,就退化为普通LRU了。

参数:innodb_old_blocks_time

介绍:老生代停留时间窗口,单位是毫秒,默认是1000,即同时知足“被访问”与“在老生代停留时间超过1秒”两个条件,才会被插入到新生代头部。

总结

(1)缓冲池(buffer pool)是一种常见的下降磁盘访问的机制;

(2)缓冲池一般以页(page)为单位缓存数据;

(3)缓冲池的常见管理算法是LRU,memcache,OS,InnoDB都使用了这种算法;

(4)InnoDB对普通LRU进行了优化:

将缓冲池分为老生代和新生代,入缓冲池的页,优先进入老生代,页被访问,才进入新生代,以解决预读失效的问题

页被访问,且在老生代停留时间超过配置阈值的,才进入新生代,以解决批量数据访问,大量热数据淘汰的问题

在这里推荐一个软件测试交流群,qq:642830685,群中会不按期的分享软件测试资源,测试面试题以及测试行业资讯,你们能够在群众积极交流技术,还有大佬为你答疑解惑,美哉美哉。
在这里插入图片描述