深入理解 InnoDB 缓冲池：性能调优指南

InnoDB 使用内存来避免每次访问都从磁盘读取数据页。缓冲池保存近期访问过的数据页和索引页；写入操作先修改内存中的页面，再将其刷回磁盘。弄清哪些页面进入缓冲池、哪些页面被淘汰，以及预热需要多长时间，有助于解释稳定运行时的性能和重启后的查询延迟。

缓冲池中有什么

innodb_buffer_pool_size 决定这块共享内存的大小。InnoDB 页面通常为 16 KiB，但创建实例时也可以把 innodb_page_size 配置为其他值。数据页、索引页和内部结构共同占用缓冲池。已在内存中的页面无需再读数据文件；缺失的页面则必须从存储设备加载。

专用数据库服务器可能适合较大的缓冲池，但不能把固定的内存百分比当作通用配置。操作系统、连接、临时操作、其他存储引擎和同机服务都需要内存。64 GiB 内存的主机配置 48 GiB 缓冲池只是需要验证的示例，并非默认建议。

应在相同时间区间内测量读取量，不要只看从服务器启动以来累计的百分比：

SHOW GLOBAL STATUS WHERE Variable_name IN (
  'Innodb_buffer_pool_read_requests',
  'Innodb_buffer_pool_reads',
  'Innodb_buffer_pool_pages_dirty',
  'Innodb_buffer_pool_wait_free'
);

区间内的未命中率为 ΔInnodb_buffer_pool_reads / ΔInnodb_buffer_pool_read_requests。如果该比率、物理读取量和查询延迟同时上升，说明活跃数据集可能无法有效地留在内存中。命中率高并不能单独证明查询很快。脏页数量与 Innodb_buffer_pool_wait_free 可用于判断刷盘压力。

为什么大范围扫描未必会赶走所有热点页面

InnoDB 使用经过改进的 LRU 列表。新读取的页面先进入 old 区域，频繁访问的页面可以晋升到 young 区域。这种中点插入方式可减轻一次性全表扫描对热点工作集的冲击。

innodb_old_blocks_pct 控制 old 区域在列表中的比例（MySQL 8.4 默认值为 37）。innodb_old_blocks_time 控制新页面晋升前的等待时间（MySQL 8.4 默认 1000 毫秒）。延长等待时间可能在大型报表运行时保护 OLTP 页面，但也可能妨碍真正有用的页面晋升。将它设置为零会取消这段等待，并非所有读密集型负载的通用解决方案。修改前应测量真实业务负载。

重启或故障切换后的预热

服务器重启后，缓存处于冷态。即使 SQL 和索引没有变化，最初的请求仍可能频繁读取数据文件。InnoDB 可以在关闭时保存页面标识符，并通过 innodb_buffer_pool_dump_at_shutdown 和 innodb_buffer_pool_load_at_startup 在启动时重新加载这些页面。innodb_buffer_pool_dump_pct 控制记录的热点页面比例。转储文件不包含页面数据本身，启动时仍需从磁盘读取。

其他方法包括让正常流量自然预热、执行范围受控且具有代表性的查询，或者在流量切换前先预热副本。预加载可能与生产请求争用 I/O，因此要限制速率并监控延迟。缓冲池填满 80% 并不代表关键查询所需的页面已经就绪。应通过代表性请求的延迟和物理读取量，并在适用时结合缓冲池加载状态，判断是否完成预热。

写入、redo 与其他结构的关系

事务修改页面后，缓冲池中的副本成为脏页。InnoDB 写入 redo 记录，以便故障后重放已提交的变更；后台刷盘随后把修改过的数据页写入文件，并推进检查点。redo 日志和缓冲池的职责不同：过于激进的脏页目标可能增加 I/O，刷盘不足则可能在之后造成压力。应根据业务要求设置持久性；如果每笔已提交事务都必须在服务器崩溃后保留，通常选择 innodb_flush_log_at_trx_commit=1。

Change Buffer 可以延迟修改尚未进入内存的非唯一二级索引页。在某些 MySQL 写入负载下，这能减少随机 I/O，但需要后续合并，并占用内存。自适应哈希索引可能加快重复查找，也会消耗内存，甚至引入竞争。两者都不是必然有益：先确认当前版本是否支持，观察相关计数器，再用代表性流量测试。特别是从 MariaDB 10.5 起，缓冲池只使用一个实例，因此设置 innodb_buffer_pool_instances=8 的建议并不适用。

实用的调优顺序

对于繁忙的订单系统，先明确真实的活跃数据集和内存预算。记录平时及高峰期的查询延迟、物理读取、脏页和 I/O。若缓冲池满时磁盘读取增加，先改善索引和 SQL 访问方式，再测试更大的缓冲池，同时观察主机的总内存使用量。若分析查询的扫描挤走热点页面，再测试 old 区域相关参数。若延迟只在重启或副本提升后增加，则测试 dump/load，并在将生产流量导入新主库前完成预热。

在 MySQL 8.4 中，多缓冲池实例可能降低多 GiB 缓冲池的并发竞争，但实例数量应以测量结果为依据，并为每个实例保留约 1 GiB 或更多空间。像 99% 这样的总体命中率目标只能作为诊断线索，不能单独充当服务目标。应在相同负载下比较修改前后效果，同时报告速度提升以及内存或 I/O 回退。

结语

缓冲池不只是一个大型缓存。其页面准入策略保护常用数据，预热决定重启后的延迟，刷盘则将内存中的写入与持久化存储连接起来。根据实际负载的测量结果并留出足够内存余量进行调优，比照搬固定配方更可靠。

本文经作者许可，根据 Duthaho 在 Medium 上的文章 改编并翻译，原文发表于 2025 年 8 月 22 日。与版本有关的细节参照了 MySQL 8.4 缓冲池文档 和 MariaDB 缓冲池文档。