InnoDB 的 buffer_pool 缓存数据页和索引页（16KB），不缓存 SQL 结果、查询计划等；命中率低于 95% 需关注，调整需满足 128MB 倍数、≤物理内存 75%～80%、多实例时单实例≥1GB 等约束。
缓冲池（Buffer Pool）到底存什么
InnoDB 的 buffer_pool 不是缓存 SQL 查询结果，而是缓存从磁盘读取的 ** 数据页（16KB）和索引页 **——包括聚簇索引、二级索引、undo 页、插入缓冲页等。只要页被访问过且未被淘汰，就可能留在其中。它不缓存查询计划、连接信息或临时表内容。
常见误解是“加大 buffer_pool 就能加速所有慢查询”，但若查询走全表扫描且数据量远超池大小，或者大量执行 ORDER BY RAND() 这类无法利用索引的语句，缓冲池命中率依然会很低。
如何查看当前 buffer_pool 使用状况
别只看 SHOW VARIABLES LIKE 'innodb_buffer_pool_size'，那只是配置值。真正要盯的是运行时状态：
-
SHOW ENGINE INNODB STATUSG→ 查看 “BUFFER POOL AND MEMORY” 段里的Database pages（已用页数）、Free buffers（空闲页）、Buffer pool hit rate（命中率，低于 95% 就该警惕） -
SELECT * FROM information_schema.INNODB_BUFFER_POOL_STATS;→ 提供更结构化指标，如pages_data、pages_dirty、pages_free -
SELECT * FROM information_schema.INNODB_BUFFER_PAGE LIMIT 5;→ 查单个页类型（注意：此表性能开销大，仅调试用）
命中率长期低于 90%，大概率说明 buffer_pool_size 设置偏小，或存在大量低效全表扫描。
调整 buffer_pool_size 的关键约束
不是“越大越好”。需同时满足三个硬性条件：
- 必须是
128MB的整数倍（低于该值会被自动上调） - 不能超过物理内存的 75%～80%，否则 OS 缺页严重，反而拖垮性能
- 若启用了
innodb_buffer_pool_instances > 1（推荐设为 CPU 核数，但 ≤ 64），总大小会均分到各实例，每个实例最小约1GB；若总大小太小（如 512MB），设多个实例反而增加锁竞争
例如：16GB 内存服务器，设 innodb_buffer_pool_size = 12G，innodb_buffer_pool_instances = 8 是合理组合；但若只给 512MB，强行设 8 实例，每个仅 64MB，Lru Manager 锁争用会上升。
脏页刷盘与刷新策略怎么影响响应延迟
脏页（pages_dirty）不及时刷回磁盘，会导致 checkpoint 延迟、主从延迟、甚至 crash recovery 时间变长。InnoDB 通过两个机制控制：
-
innodb_io_capacity：设为磁盘随机 IOPS 能力（如 SATA SSD 约 200～500，NVMe 可设 2000+），它决定后台线程每秒最多刷多少页 -
innodb_max_dirty_pages_pct：默认 75，当脏页占比超该值，InnoDB 会主动加压刷盘；若业务写入密集，可降到 50～60，避免突发 flush 拖慢事务提交
注意：innodb_flush_log_at_trx_commit = 1 和 sync_binlog = 1 下，刷脏页本身不阻塞 commit，但若 io_capacity 过低 + 脏页堆积多，后台刷盘跟不上，最终仍会触发同步刷盘逻辑，导致 Query OK 延迟升高。
缓冲池管理本质是权衡：既要减少磁盘 IO，又要防止内存驻留失效页过多、刷盘压力集中。很多线上问题不是 size 设小了，而是没配好 io_capacity 和 dirty_pages_pct 的组合。
