❝

扫描下方二维码或者微信搜索公众号菜鸟飞呀飞，即可关注微信公众号，阅读更多Spring源码分析、Java并发编程、Netty源码系列和MySQL工作原理文章。

❞

1. 开篇

MySQL 在查询数据时，对于 InnoDB 存储引擎而言，会先将磁盘上的数据以页为单位，先将数据页加载进内存，然后以缓存页的形式存放在「Buffer Pool」中。Buffer Pool 是 InnoDB 的一块内存缓冲区，在 MySQL 启动时，会按照配置的缓存页的大小，将 Buffer Pool 缓存区初始化为许多个缓存页，默认情况下，缓存页大小为 16KB。

❝

为了方便理解，对于磁盘上的数据所在的页，叫做数据页，当加载进 Buffer Pool 中后，叫做缓存页，这两者是一一对应的

❞

在 MySQL 启动初期，Buffer Pool 中的这些缓存页都是处于空闲状态，也就是还没有被使用，而随着 MySQL 的运行时间越来越长，这些缓存页渐渐地都被使用了，用来存放从磁盘上加载的数据页，导致空闲的缓存页就越来越少。当某一时刻，所有空闲的缓存页都被使用了，那么这个时候，从磁盘加载到内存中的数据页该怎么办呢？

2. LRU算法

既然没有空闲缓存页了，而又想使用缓存页，那么最简单的办法就是淘汰一个缓存页。应该淘汰谁呢？当然是淘汰那个最近一段时间最少被访问过的缓存页了，这种思想就是典型的 LRU 算法了。

LRU 是 Least Recently Used 的简写，这个算法的实现就是淘汰最久未使用的数据，它通过维护一个链表，每当访问了某个数据时，就将这个数据加入到链表的头部，如果数据本身存在于链表中，那么就将数据从链表的中间移动到链表的头部，这样最终下来，在链表尾部的数据一定就是最久未被使用的数据了，因此可以将其淘汰。

将 LRU 算法应用到缓存页的淘汰策略上，那么就是在 InnoDB 存储引擎层内部，维护了一个链表，这些链表中的元素存储的就是指向缓存页的指针。

在 MySQL 启动的时候，这个链表为空。MySQL 启动以后，在进行数据查询时，InnoDB 会先判断要查询的数据所在的数据页，是否存在于 Buffer Pool 的缓存页当中，如果不存在，就从磁盘中读取对应数据页，存放到 Buffer Pool 一个空闲的缓存页当中，然后将这个缓冲页放入到链表的头部；如果要查询的数据已经存在于 Buffer Pool 当中了，那么就将对应的缓存页从链表的中间移动到链表头部。

这样随着 MySQL 的运行，空闲的缓存页越来越少，LRU 链表越来越长，直到某一时刻，剩余的空闲缓存页数为 0，当需要申请一个新的空闲缓存页的时候，就需要淘汰一个缓存页了，此时只需要把链表尾部的那个缓存页刷入到磁盘，然后清空缓存页里面的数据，这样就空余出一个新的缓存页了。

3. LRU 链表带来的问题

咋一看，似乎 LRU 链表完美解决了缓存页淘汰的问题。但理想很丰满，现实却很骨感，如果直接使用这种 LRU 算法的话，在 MySQL 中就会存在很大的问题。

3.1 全表扫描

在 MySQL 中经常会出现全表扫描，一种是开发人员对索引的使用不当导致的，一种是业务如此，无法避免。

当出现全表扫描时，InnoDB 会将该表的数据页全部从磁盘文件加载进缓存页中，这些缓存页会被加入到 LRU 链表中。如果进行全表扫描的对象是一张非常大的表，可能是几十 GB 的数据，而且这张表记录的是类似于账户流水、操作日志等使用不频繁的数据，这个时候如果 LRU 链表已经满了，现在我们就要淘汰一部分缓存页，腾出空间来存放全表扫描出来的数据。这样就会因为全表扫描的数据量大，需要淘汰的缓存页多，导致在淘汰的过程中，极有可能将需要频繁使用到的缓存页给淘汰了，而放进来的新数据却是使用频率很低的数据，甚至是这一次使用之后，后面几乎再也不用，如操作日志等。

最终导致的现象就是，当我们在对这些使用不频繁的大表进行全表扫描之后，在一段时间内，Buffer Pool 缓存的命中率明显下降，SQL 的性能也明显下降，因为常用的缓存页被淘汰了，再进行查询时，需要从重新磁盘读取，发生磁盘 IO，性能下降。所以，如果 MySQL 只是简单的使用 LRU 算法，那么碰到全表扫描时，就会存在性能下降的问题，甚至在高并发场景下，成为性能瓶颈。

3.2 预读

预读是 InnoDB 引擎的一个优化机制，当你从磁盘上读取某个数据页，InnoDB 可能会将与这个数据页相邻的其他数据页也读取到 Buffer Pool 中。

InnoDB 为什么要这样做呢？因为从磁盘读取数据时发生的磁盘 IO 是随机 IO，性能差。当你读取某一个数据页时，InnoDB 会猜测你可能也需要下一个数据页的数据，如果一次能连着读取多个数据页，那么对其他的数据页而言，这是顺序读取（节省了寻道时间、磁头旋转时间），相对较快，那这样就能提升一点性能。

在两种情况下会触发预读机制：

1. 顺序的访问了磁盘上一个区的多个数据页，当这个数量超过一个阈值时，InnoDB 就会认为你对下一个区的数据也感兴趣，因此触发预读机制，将下一个区的数据页也全都加载进 Buffer Pool。这个阈值由参数 「innodb_read_ahead_threshold」 控制，默认为 56。 可以通过如下命令查看：

show variables like 'innodb_read_ahead_threshold';

2. 如果 Buffer Pool 中已经缓存了同一个区数据页的个数超过 13 时，InnoDB 就会将这个区的其他数据页也读取到 Buffer Pool 中。这个开关由参数 「innodb_random_read_ahead」 控制，默认是关闭的。

show variables like 'innodb_random_read_ahead';

如果 MySQL 仅是简单的使用 LRU 算法，那么预读机制和全表扫描带来的问题类似，预读机制会将其他的数据页也加载进内存，当 LRU 链表满时，可能将我们频繁访问的缓存页给淘汰，从而导致性能下降。

4. 冷热分离

实际上，MySQL 确实没有直接使用 LRU 算法，而是在 LRU 算法上进行了优化。

从上面的全表扫描和预读机制的问题分析中，我们可以看到，根本原因就是从磁盘上新读取到的数据页，在加载进 Buffer Pool 时，可能将我们频繁访问的数据给淘汰，也就是出现了冷热数据的现象。因此，MySQL 的优化思路就是：对数据进行冷热分离，将 LRU 链表分成两部分，一部分用来存放冷数据，也就是刚从磁盘读进来的数据，另一部分用来存放热点数据，也就是经常被访问到数据。

其中，存放冷数据的区域占这个 LRU 链表的多少呢？这由参数 「innodb_old_blocks_pct」 控制，默认是 37%（约八分之三）。冷热分离的 LRU 链表示意图如下（图片来自于MySQL官方文档）。

show variables like 'innodb_old_blocks_pct';