Buffer Pool 介绍
MySQL 的数据是存储在磁盘中的，但是直接读取磁盘数据性能差。所以为了提升查询性能，加入缓冲池 buffer pool。有了 buffer pool 之后：
- 当读取数据时，如果数据存在于 Buffer Pool 中，客户端就会直接读取 Buffer Pool 中的数据，否则再去磁盘中读取。
- 当修改数据时，首先是修改 Buffer Pool 中数据所在的页，然后将其页设置为脏页，最后由后台线程将脏页写入到磁盘。
buffer pool 大小
在 MySQL 启动时，会申请一段连续的存储空间作为 buffer pool，默认配置下 buffer pool 有 128 MB。
可以修改 innodb_buffer_pool_size 参数来设置 buffer pool 的大小，一般建议设置成**可用物理内存的 60%~80%**。
缓存内容
InnoDB 在存储数据时，会划分若干个页，以页作为磁盘和内存交互的基本单位。所以，buffer pool 也是按照页划分的，一个页的默认大小为 16 KB。
在 MySQL 启动的时候，InnoDB 会为 Buffer Pool 申请一片连续的内存空间，然后按照默认的 16KB 的大小划分出一个个的页， Buffer Pool 中的页就叫做缓存页。MySQL 刚启动时，使用的虚拟内存空间很大，但是物理内存空间很小，只有这些虚拟内存被访问后，操作系统才会触发缺页中断，接着将虚拟地址和物理地址建立映射关系。
Buffer pool 除了缓存数据页和索引页，还包括了回滚页、插入换成、自适应哈希索引、锁信息等。
为了更好的管理这些在 Buffer Pool 中的缓存页，InnoDB 为每一个缓存页都创建了一个控制块，控制块信息包括「缓存页的表空间、页号、缓存页地址、链表节点」等等。
控制块也是占有内存空间的，它是放在 Buffer Pool 的最前面，接着才是缓存页。
控制块的大小不等于缓存页的大小，所以控制块和缓存页之间可能有碎片空间。
如何管理 Buffer Pool
管理空闲页
Buffer pool 管理的缓存页中，既有空闲的又有被使用的，为了能够快速找到空闲页，可以使用链表结果，将空闲缓存页的控制块作为链表的节点，空闲缓存页的控制块之间连成双向链表，为 Free 链表（空闲链表）。
Free 链表上除了有控制块，还有一个头节点，该头节点包含链表的头节点地址，尾节点地址，以及当前链表中节点的数量等信息。
管理脏页
Buffer pool 可以提高读性能，也可以提高写性能。在更新数据时，不需要每次都要写入磁盘，而是将 Buffer Pool 对应的缓存页标记为脏页，然后再由后台线程将脏页写入到磁盘。
那为了能快速知道哪些缓存页是脏的，于是就设计出 Flush 链表，链表节点是脏页的控制块。
提高缓存命中率
Buffer pool 通过 LRU 链表，将干净页（查询但没有修改）和脏页链接起来，优化缓存页淘汰机制，提高缓存命中率。所以 buffer pool 中有三种链表：free 链表、flush 链表和 lru 链表。
但是 MySQL 没有使用简单的 LRU 算法，因为简单的 LRU 算法有预读失效和 buffer pool 污染两个问题。
预读失效
根据局部性原理，MySQL 在加载数据页时，会提前把它相邻的数据页一并加载进来，目的是为了减少磁盘 IO。但是可能这些被提前加载进来的数据页，并没有被访问，相当于这个预读是白做了，这个就是预读失效。
如果使用简单的 LRU 算法，就会把预读页放到 LRU 链表头部，而当 Buffer Pool空间不够的时候，还需要把末尾的页淘汰掉。如果这些预读页如果一直不会被访问到，就会出现一个很奇怪的问题：不会被访问的预读页却占用了 LRU 链表前排的位置，而末尾淘汰的页，可能是频繁访问的页，这样就大大降低了缓存命中率。
要避免预读失效带来影响，最好就是让预读的页停留在 Buffer Pool 里的时间要尽可能的短，让真正被访问的页才移动到 LRU 链表的头部，从而保证真正被读取的热数据留在 Buffer Pool 里的时间尽可能长。
MySQL 是这样做的，它改进了 LRU 算法，将 LRU 划分了 2 个区域：old 区域 和 young 区域。young 区域在 LRU 链表的前半部分，old 区域则是在后半部分。old 区域占整个 LRU 链表长度的比例可以通过 innodb_old_blocks_pct 参数来设置，默认是 37，代表整个 LRU 链表中 young 区域与 old 区域比例是 63:37。
划分这两个区域后，预读的页就只需要加入到 old 区域的头部，当页被真正访问的时候，才将页插入 young 区域的头部。如果预读的页一直没有被访问，就会从 old 区域移除，这样就不会影响 young 区域中的热点数据。
buffer pool 污染
当某一个 SQL 语句扫描了大量的数据时，在 Buffer Pool 空间比较有限的情况下，可能会将 Buffer Pool 里的所有页都替换出去，导致大量热数据被淘汰了，等这些热数据又被再次访问的时候，由于缓存未命中，就会产生大量的磁盘 IO，MySQL 性能就会急剧下降，这个过程被称为 Buffer Pool 污染。
like 语句或者以没有索引的数据列作为查询条件，进行查询时会进行全表扫描。很多缓冲页其实只会被访问一次，但是它却只因为被访问了一次而进入到 young 区域，从而导致热点数据被替换了。
LRU 链表中 young 区域就是热点数据，只要提高进入到 young 区域的门槛，就能有效地保证 young 区域里的热点数据不会被替换掉。MySQL 是这样做的，进入到 young 区域条件增加了一个停留在 old 区域的时间判断。具体是这样做的，在对某个处在 old 区域的缓存页进行第一次访问时，就在它对应的控制块中记录下来这个访问时间：
- 如果后续的访问时间与第一次访问的时间在某个时间间隔内，那么该缓存页就不会被从 old 区域移动到 young 区域的头部；
- 如果后续的访问时间与第一次访问的时间不在某个时间间隔内，那么该缓存页移动到 young 区域的头部；
这个间隔时间是由 innodb_old_blocks_time 控制的，默认是 1000 ms。也就说，只有同时满足「被访问」与「在 old 区域停留时间超过 1 秒」两个条件，才会被插入到 young 区域头部，这样就解决了 Buffer Pool 污染的问题 。
另外，MySQL 针对 young 区域其实做了一个优化，为了防止 young 区域节点频繁移动到头部。young 区域前面 1/4 被访问不会移动到链表头部，只有后面的 3/4被访问了才会。
脏页刷入磁盘时机
下面几种情况会触发脏页的刷新：
- 当 redo log 日志满了的情况下，会主动触发脏页刷新到磁盘；
- Buffer Pool 空间不足时，需要将一部分数据页淘汰掉，如果淘汰的是脏页，需要先将脏页同步到磁盘；
- MySQL 认为空闲时，后台线程会定期将适量的脏页刷入到磁盘；
- MySQL 正常关闭之前，会把所有的脏页刷入到磁盘；
如果偶尔会出现一些用时稍长的 SQL，这可能是因为脏页在刷新到磁盘时可能会给数据库带来性能开销，导致数据库操作抖动。如果间断出现这种现象，就需要调大 Buffer Pool 空间或 redo log 日志的大小。