缓冲池 buffer pool的解释

背景，通常情况下，我们为了减少数据库压力一班都会加个缓存机制，先从缓存查，查不到再从数据库查，那么我们的数据库也不想老读磁盘，如何优化呢？那就是也加个缓存也就是这里的buffer pool了，缓存页数据与索引数据，把磁盘上的数据加载到缓冲池，避免每次访问都进行磁盘IO，起到加速访问的作用。

一 .buffer pool是什么？

咱们跟别的不一样，咱们先说结论，再分析为啥。

• 缓冲池(buffer pool)是一种降低磁盘访问的机制；
• 缓冲池通常以·页(page)·为单位缓存数据；
• 缓冲池的常见管理算法是LRU，memcache，OS，InnoDB都使用了这种算法；
• InnoDB对普通LRU进行了优化： - 将缓冲池分为老生代和新生代，入缓冲池的页，优先进入老生代，页被访问，才进入新生代，以解决预读失效的问题 - 页被访问，且在老生代停留时间超过配置阈值的，才进入新生代，以解决批量数据访问，大量热数据被淘汰的问题

二 .buffer pool的设计思想

2.1 什么是预读？

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

为什么我们觉得需要预读呢或者说预读为什么有效？

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

2.2 InnoDB的缓冲池设计的思路？

• 1.磁盘访问按页读取能够提高性能，所以缓冲池一般也是按页缓存数据；
• 2.预读机制启示了我们，能把一些“可能要访问”的页提前加入缓冲池，避免未来的磁盘IO操作；

2.3 InnoDB是以什么算法，来管理这些缓冲页呢？

通常情况下这类缓存一般使用的都是LRU算法，比如我们操作系统、redis的数据淘汰，但是我们Mysql在原LRU的基础上做了一定的增强；

2.4 怎么知道数据页是否被缓存？

数据库中有一个** 数据页缓存哈希表**我，用表空间号+数据页号，作为一个key，然后缓存页的地址作为value 表空间号+数据页号 = 缓存页地址

2.5 free链是干啥的？

作用：帮助我们找到空闲的缓存页 描述：是一个双向链表，链表节点是空闲的缓存页对应的描述信息块（空的缓存页） 记载进free的时机：

• 1. 数据库启动时，会申请内存创建buffer pool，buffer pool分成一个个缓存页及其缓存页描述信息块，描述信息块加入到free链表中
• 1. 如果缓存页不够用了，会把lru冷数据区尾部的缓存页刷盘，清空；该缓存页从lru链表和flush链表中移除，加入到free链表中
• 3.mysql后台线程也会定时把lru冷数据区尾部的缓存页刷盘，清空；定时把flush链表中的缓存页刷盘，清空，加入到free链表中
• 链表上除了描述信息块，还有一个基础节点，存储了free链有多少个描述信息块，也就是有多少个空闲的缓存页
• 当我们加载数据的时候，会从free链中找到空闲的缓存页，把数据页的表空间号和数据页号写入描述信息块；加载数据到缓存页后，会把缓存页对应的描述信息块从free链表中移除

image

2.6 什么是脏缓存页？

被更新过的缓存页，数据和磁盘上的数据不一致，所以是脏缓存页 脏缓存页的数据是要刷到磁盘上的

2.7 flush链表

是一个双向链表，链表结点是被修改过的缓存页的描述信息块（更新过的缓存页） 作用：帮我们找到脏缓存页，也就是需要刷盘的缓存页，如果更新了缓存页，会把该缓存页加入到flush链表中 和free链表一样，也有一个基础结点，链接首尾结点，并存储了有多少个描述信息块 最后要把flush链表上结点对应的缓存页刷盘，后台线程会在MySQL不怎么繁忙的时候，找个时间把flush链表中的缓存页都刷入磁盘中，这样被你修改过的数据，迟早都会刷入磁盘的；缓存页从flush链表中移除，加入到free链表当中

image

三.buffer pool数据淘汰策略的设计思路

3.1 普通Lru有什么问题？

• 1.容易出现预读失效 预读：由于预读(Read-Ahead)，提前把页放入了缓冲池，但最终MySQL并没有从页中读取数据，称为预读失效。
• 2.容易出现缓冲池污染 缓冲池污染：当某一个SQL语句，要批量扫描大量数据时，可能导致把缓冲池的所有页都替换出去，导致大量热数据被换出，MySQL性能急剧下降，这种情况叫缓冲池污染。 eg： select * from user where name like "%shenjian%"; 虽然结果集可能只有少量数据，但这类like不能命中索引，必须全表扫描，就需要访问大量的页：

buffer poll为了解决这两个问题，就在普通LRU基础上做了一些优化，尽量让真正的热点页可以在buffer pool里存活时间更长

3.2 buffer poll 优化LRU算法，解决预读失效做的优化

他讲Lru数据的页链表，分成两个部分，新生代和老年代

具体方法是：

• 1. 将LRU分为两个部分： 新生代(new sublist) 老生代(old sublist)
• 2.新老生代收尾相连，即：新生代的尾(tail)连接着老生代的头(head)；
• 3.新页（例如被预读的页）加入缓冲池时，只加入到老生代头部： 如果数据真正被读取（预读成功），才会加入到新生代的头部 如果数据没有被读取，则会比新生代里的“热数据页”更早被淘汰出缓冲池

3.3 buffer pool 增加“老年代停留时间窗口”机制解决缓冲池污染问题

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

• 假设T=老生代停留时间窗口；
• 插入老生代头部的页，即使立刻被访问，并不会立刻放入新生代头部；短时间内被大量加载的页，并不会立刻插入新生代头部，而是优先淘汰那些短期内仅仅访问了一次的页。
• 只有满足“被访问”并且“在老生代停留时间”大于T，才会被放入新生代头部；

3.4 buffer pool 优化的重要参数

3.4.1 innodb_buffer_pool_size

• 参数：innodb_buffer_pool_size
• 介绍：配置缓冲池的大小，在内存允许的情况下，DBA往往会建议调大这个参数，越多数据和索引放到内存里，数据库的性能会越好。

3.4.2 innodb_old_blocks_pct

• 参数：innodb_old_blocks_pct
• 介绍：老生代占整个LRU链长度的比例，默认是37，即整个LRU中新生代与老生代长度比例是63:37。 画外音：如果把这个参数设为100，就退化为普通LRU了。

3.4.3 innodb_old_blocks_time

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