MySQL InnoDB buffer_pool缓存

InnoDB缓存机制

InnoDB缓存的是以页为基本单位的，一页的大小是16KB。其有如下的作用：
1、加速读就是当需要访问一个数据页的时候，如果这个页已经在缓存池中，那么就不再需要访问磁盘，直接从缓冲池中就能获取这个页面的内容。
2、加速写就是当需要修改一个数据页的时候，先将这个页在缓冲池中进行修改，记下相关的 redo log，这个页的修改就算已经完成了。至于这个被修改的页什么时候真正刷新到磁盘，这个是 buffer pool 后台刷新线程来完成的。
由于物理服务器的内存大小是有限的，buffer pool的大小不可能无限大，InnoDB提供了如下的参数用于控制InnoDB的大小。

show variables like 'innodb_buffer_pool_size';//buffer pool的总大小
show variables like 'innodb_buffer_pool_instances';//buffer pool个数

我们一般可以把参数innodb_buffer_pool_size设置成物理内存的60%~80%。
既然buffer有那么重要的作用，那么缓存命中率就是一个十分重要的指标了，可以通过如下的语句查看：

show engine InnoDB status;

这个语句的输出中包含了”Buffer pool hit rate”，如下的输出中表示命中率为100%。

Buffer pool hit rate 1000 / 1000

InnoDB缓存淘汰策略

InnoDB缓存管理是用的LRU（最近最少使用 Least Recently Used）算法，这个算法的核心思想是淘汰最久没有使用的数据。

基本的LRU算法

基本的LRU算法如下所示：
1、LRU算法一般是通过双向链表+Hash算法实现，其存储结构如下图所示：

通过散列表，可以在O(1)的时间复杂度内找到数据，由于是双向链表，可以在O(1)的时间复杂度内删除链表中的任何一个数据。
2、新数据插入到链表头部。
3、每当缓存命中（即缓存数据被访问），则将数据移到链表头部。
4、当链表满的时候，将链表尾部的数据丢弃。
如果InnoDB也使用基本的LRU算法，那么当我们扫描一个冷门的大表且大表超过了缓存的大小，根据LRU淘汰算法，将会导致缓存的热点数据全部被清空。从而严重影响缓存命中率。

InnoDB改进的LRU淘汰算法

由于基本的LRU算法，会导致缓存命中率底下。为此InnoDB使用了改进型的LRU淘汰算法：
1、InnoDB将LRU链表按照5：3的比率花费成了2部分，其再链表的5/8处插入一个LRU_old指针，这个指针的前5/8部分为young区域，后3/8部分为old区域，LRU_old指针指向了old的区域的头部；
2、新插入数据时，插入到old区域的头部；
3、如果数据在LRU缓存中且在young区域，则移动到链表的头部；
4、如果数据在LRU缓存中且在old区域且存在的时间在1秒以内，则不动数据在链表中的位置；
5、如果数据在LRU缓存中且在old区域且存在的时间超过1秒，则移动到链表的头部；
6、数据不管是 在young区域还是old区域，如果不会被访问到，最后都会被移动到链表的尾部，然后删除掉。
1 秒这个时间，是由参数 innodb_old_blocks_time 控制的。其默认值是 1000，单位毫秒。
还是以上面的例子“当我们扫描一个冷门的大表且大表超过了缓存的大小”来说明：
1、新插入的数据放入到old区域的头部；
2、一页中往往存在多行数据，为此会访问多次，但是同一页面上其他数据往往很快就可以遍历完成了（基本都在1秒以内）。因此再次被访问到的时间在1秒以内，从而数据还是保留在old区域；
3、继续扫描下一个页面的数据，重复1与2的步骤；
从如上的过程中可以看出一次扫描大表的数据，始终都进入不了young区域，从而不会导致热点数据不会淘汰。
当然如果频繁的扫描大表，如果大表大于old区域的大小，那么可能会导致新的热点数据（包括大表的数据）进入不到young区域，频繁的被淘汰；如果大表小于old区域，大表的全量数据会保存到young区域中。为此我们需要避免频繁扫描大表。
相似的在BNL Join的表连接语句中，如果被驱动表是一个冷门的大表。如果被驱动表大于old区域的大小，那么可能会导致新的热点数据进入不到young区域，频繁的被淘汰；如果被驱动表小于old区域且多次扫描被驱动表的间隔超过1秒，那么被驱动表的全量数据会保存到young区域中，从而导致young区域的热点数据被淘汰了。这2种情况都会导致缓存命中率下降。这也是我们需要避免BNL Join算法的原因之一。