MySQL中的Buffer Pool到底是个什么玩意儿

Buffer Pool简介

我们都知道MySQL中的数据都是存储在磁盘上的，那么如果每次都去磁盘上读取数据的话，那么效率肯定很低，所以在内存中就存在一个缓冲池，也就是这篇博客的主角Buffer Pool，磁盘中的数据会被缓存到Buffer Pool中，就不需要再去磁盘中重新读取数据了

既然Buffer Pool是存在于内存中的话，那么大小肯定就有限制了，默认情况下是128M，当然相对于内存大的机器，可以适当的增加Buffer Pool的大小，对于InnoDB储存引擎而言，Buffer Pool配置可以通过 innodb_buffer_pool_size 来设置他的大小

数据库中的数据都是存储在一个个的数据页中，大小是16K。那么将数据页的信息放入Buffer Pool中的话，也应该是一个个页的形式，一般称之为缓存页，缓存页和数据页的大小是一一对应的

现在问题来了，既然需要将数据页放入到Buffer Pool中的缓存页，那么如何知道Buffer Pool中哪些缓存页是空的，可以用来存放数据，这里首先需要加入一个概念，就是一个缓存页除了存放数据之外，还有一个描述信息，可以理解为一篇文章的一个标题，这个描述信息中包含了数据页所属的表空间、数据页编号、缓存页在Buffer Pool中的地址等等，一个描述信息代表了一个描述数据块，也是有大小的，大概相当于一个缓存页的5%

free链表

讲完了描述信息，那么他跟缓存页是否为空有什么联系呢？其实这里有一个双向链表，叫做free链表。链表中的每个节点就是一个空闲数据页的描述数据块，free链表还有一个基础节点，引用了链表的头结点和尾结点，同时还存储了链表中还有多少节点，这样我们就能知道还有多少缓存页是空闲的了

free链表每个节点就是一个描述数据块，前后两个指针（free_pre和free_next）分别指向了上一个节点和下一个节点，当一个缓存页被一个数据页的数据放入了之后，就会从free链表中将这个缓存页的描述数据块给去掉，也就是分别将前后指针置为null即可

数据库中同时会维护一个哈希表数据结构，key为表空间号 + 数据页号，value为缓存页地址，当数据库使用一个数据页的时候，就会去这个哈希表中查询一下这个数据页是否存在，如果已经存在的话，就说明Buffer Pool已经有数据可以直接使用了，否则就按照上面的逻辑将数据页加载到缓存页中

flush链表

数据库中的数据以数据页的形式加载到Buffer Pool中，然后就在内存中进行各种增删改的操作，此时数据还没有写回到磁盘中，所以这些数据也就是脏数据了，那么必然会导致Buffer Pool中的缓存页中有些是脏数据，有些只是查询了而已，还不是脏数据

此时又有一个链表，称之为flush链表，flush链表的数据结构和free链表的数据结构是一致的，经过增删改的缓存页就会加入flush链表的节点中，之后这些缓存页的脏数据就会被flush到磁盘上，完成数据持久化的操作

缓存页的LRU机制

之前我们提到了Buffer Pool的大小有限，那么里面的缓存页肯定也是有限的，如果缓存页都被数据页中的数据填满了，那不就无法加载新的数据进来了吗？所以我们需要一个LRU算法来淘汰一部分缓存页，Buffer Pool的做法是将缓存页上的脏数据刷入磁盘中，这样就可以空闲出来一部分的缓存页了

实现这个LRU机制依靠的是一个LRU链表，这个链表跟我们之前说过的free链表、flush链表都是一样的数据结构。只要有数据的缓存页，都会存在于LRU链表中，而且最近被加载的数据页都会在LRU链表的头部，链表中再次被查询或者修改的缓存页会再次放到头部去，那么在淘汰缓存的时候，就需要从尾部开始淘汰

上面的方案乍一看感觉好像可以，但是实际情况下，可能会遇到两个问题，第一个问题是MySQL的缓存预读机制，缓存预读的意思是当从磁盘中加载一个数据页的时候，也可能会连带着把这个数据页相邻的其他数据页也加载到缓存中（局部性原理），但是其实预读的那一部分数据可能根本不会被使用到，那么链表头可能会出现一些无效的热数据；另外一个问题就是全表扫描了，这个应该就不用解释了，全表扫描也有可能产生大量无效的热数据

那么MySQL中的LRU机制到底是怎么做的呢？其实LRU链表被分为了两部分，一部分是热数据，一部分是冷数据（冷数据默认占比37%）。LRU链表的头部连接着热数据区，然后是冷数据区，最后才到链表尾部，看起是这样的

当数据一开始被加载到缓存页中的时候，其实是放在冷数据链表头的，默认情况下，如果1秒之内数据被访问到了，就会被放到热数据的链表头上，那么如果热数据区被填满的话，数据会降级到冷数据的链表头上，冷数据区也不够用的话，就从冷数据区的尾部开始淘汰

除了冷热数据区外，MySQL对这部分还有一个优化，那就是只有在热数据区域的后3/4部分的缓存页被访问到了，才会移动到链表头去
前1/4部分的缓存页即使频繁访问到，也不会造成缓存页移动，可以减少链表中的节点移动

你以为这样就完了吗？其实在还有空闲缓存页的时候，也会有一个后台线程执行一个定时任务，每个一段时间就将冷数据区尾部的缓存页刷入到磁盘中（如果冷数据只是查询没有被修改的话，那么直接释放内存即可，不需要刷盘），然后将他们加入到free链表中。在热数据区域中频繁被访问到的缓存页其实也是有机会被刷入到磁盘中去的，会有一个后台线程，在MySQL不怎么繁忙的时候，将flush链表中的缓存页刷入到磁盘中，至此LRU机制就已经优化到极致了

最后再补一张Buffer Pool的整体结构图