MySQL Buffer Pool深度解析：当缓存页不足时如何基于LRU算法进行淘汰 - 详解
1. 问题引入：free链表空了怎么办？
在之前的文章中，我们详细讲解了MySQL Buffer Pool中缓存页的划分、free链表的管理，以及数据页从磁盘加载到缓存页的过程。今天我们来分析一个更实际的问题：当Buffer Pool中的空闲缓存页用完时，系统该如何处理？
1.1 缓存页耗尽的必然性
随着数据库持续运行，不断有数据页从磁盘加载到Buffer Pool中：
- 每次数据加载都会从free链表获取一个空闲缓存页
- free链表中的节点会越来越少
- 最终必然出现
free链表为空的情况
磁盘数据页 → 查找free链表 → 获取空闲缓存页 → 加载数据当free链表耗尽时，新的数据页将无法加载，此时必须淘汰部分现有缓存页。
2. 淘汰策略：该把谁"请"出内存？
2.1 什么是淘汰缓存页？
淘汰缓存页是指：
- 将被修改过的缓存页数据刷新到磁盘（如果它是脏页）
- 清空该缓存页
- 将其重新加入free链表，变为可用状态
这个过程确保了内存资源的循环利用，但引出一个关键问题：应该淘汰哪些缓存页？
3. 核心指标：缓存命中率
为了做出最优淘汰决策，MySQL引入了缓存命中率的概念：
| 场景 | 访问频率 | 命中率评估 | 淘汰优先级 |
|---|---|---|---|
| 缓存页A | 100次请求中30次访问 | 高命中率 | 保留 |
| 缓存页B | 加载后仅访问1次，后续100次请求无访问 | 低命中率 | 优先淘汰 |
核心原则：优先淘汰"占着茅坑不拉屎"的缓存页——即那些长期不被访问却占用内存资源的页面。
4. LRU链表：智能淘汰的指挥官
4.1 LRU基本概念
MySQL通过LRU链表（Least Recently Used，最近最少使用）来实现智能淘汰：
工作原理：最近被访问的缓存页移动到链表头部，久未访问的页面自然沉降到尾部。
4.2 LRU链表运作机制
数据加载时
当从磁盘加载数据页到缓存页：
- 将该缓存页的描述信息块放入LRU链表头部
- 表示这是最新被使用的页面
[新加载的缓存页] → LRU Head → ... → LRU Tail数据访问时
当查询或修改某个已存在的缓存页：
- 无论该缓存页在LRU链表的哪个位置
- 立即将其移动到链表头部
- 表示它刚被访问过，近期可能再次被访问
LRU Tail中的缓存页被访问 → 移动到LRU Head淘汰决策时
当需要腾出空闲缓存页：
- 直接从LRU链表尾部选取
- 尾部的页面就是"最近最少使用"的页面
- 将其刷新到磁盘后清空
5. 技术图解
图1：free链表耗尽的场景
Buffer Pool (128MB)
┌─────────────────────────────────────┐
│ [数据] [数据] [数据] ... [数据] │
│ 缓存页 缓存页 缓存页 缓存页 │
└─────────────────────────────────────┘▲│ 无法加载新数据页│
磁盘文件 ────────────→ X (无空闲缓存页)图2：LRU链表驱动的淘汰流程
1. 识别LRU链表尾部页面（最少使用）↓
2. 如果是脏页，刷新到磁盘↓
3. 清空缓存页，加入free链表↓
4. 加载新数据页到腾出的空间↓
5. 新页面插入LRU链表头部6. 思考题解答：表/行 vs 表空间/数据页
问题：SQL中的表、行与表空间、数据页之间是什么关系？
答案：
- 逻辑概念：表、列、行——面向开发者的抽象，关注数据结构
- 物理概念：表空间、数据页——面向存储的实现，关注数据在磁盘的组织方式
类比：
就像你看一本书，只关注"章节"和"段落"（逻辑），而不必关心"纸张"和"印刷墨迹"（物理）。数据库自动将逻辑结构映射为物理存储。
7. 总结要点
- free链表耗尽是常态：持续的数据加载必然导致空闲页用完
- LRU是淘汰依据：通过访问时间戳智能判断页面热度
- 头部-尾部机制：热点数据在头部，冷数据自然沉降尾部
- 性能保障：确保内存中保留的都是高价值数据，最大化缓存命中率
系列预告：下一篇文章将深入探讨MySQL LRU算法的优化细节，包括如何解决"全表扫描污染缓存"等经典问题。
参考资料：《MySQL专栏》
版权说明：本文内容整理自狸猫技术窝MySQL专栏，仅供学习交流使用。