博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
MySQL——缓冲池 (buffer pool)原理和分析
阅读量:343 次
发布时间:2019-03-04

本文共 3046 字,大约阅读时间需要 10 分钟。

摘要

应用系统分层架构,为了加速数据访问,会把最常访问的数据,放在缓存 (cache) 里,避免每次都去访问数据库。操作系统,会有缓冲池 (buffer pool) 机制,避免每次访问磁盘,以加速数据的访问。MySQL 作为一个存储系统,同样具有缓冲池 (buffer pool) 机制,以避免每次查询数据都进行磁盘 IO。

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

缓存表数据与索引数据,把磁盘上的数据加载到缓冲池,避免每次访问都进行磁盘 IO,起到加速访问的作用。

速度快,那为啥不把所有数据都放到缓冲池里

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

(1)缓存访问快,但容量小,数据库存储了 200G 数据,缓存容量可能只有 64G;

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

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

如何管理与淘汰缓冲池,使得性能最大化呢?

什么是预读?

磁盘读写,并不是按需读取,而是按页读取,一次至少读一页数据(一般是 4K),如果未来要读取的数据就在页中,就能够省去后续的磁盘 IO,提高效率。

预读为什么有效?

数据访问,通常都遵循 “集中读写” 的原则,使用一些数据,大概率会使用附近的数据,这就是所谓的“局部性原理”,它表明提前加载是有效的,确实能够减少磁盘 IO。

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

(1)磁盘访问按页读取能够提高性能,所以缓冲池一般也是按页缓存数据;

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

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

最容易想到的,就是 LRU(Least recently used)。OS 都会用 LRU 来进行页置换管理,但 MySQL 的玩法并不一样。

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

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

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

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

如上图,假如管理缓冲池的 LRU 长度为 10,缓冲了页号为 1,3,5…,40,7 的页。假如,接下来要访问的数据在页号为 4 的页中:

(1)页号为 4 的页,本来就在缓冲池里;

(2)把页号为 4 的页,放到 LRU 的头部即可,没有页被淘汰;

为了减少数据移动,LRU 一般用链表实现。假如,再接下来要访问的数据在页号为 50 的页中:

(1)页号为 50 的页,原来不在缓冲池里;

(2)把页号为 50 的页,放到 LRU 头部,同时淘汰尾部页号为 7 的页;

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

这里有两个问题:

(1)预读失效;

(2)缓冲池污染;

什么是预读失效?:由于预读 (Read-Ahead),提前把页放入了缓冲池,但最终 MySQL 并没有从页中读取数据,称为预读失效。

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

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

(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,才会被插入新生代头部。

总结

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

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

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

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

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

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

参考

 

转载地址:http://cwjh.baihongyu.com/

你可能感兴趣的文章