缓冲池是 InnoDB 专用于缓存数据页、索引页等的连续内存区域，核心作用是减少磁盘 IO 和批量刷盘；命中率低于 95% 会导致 QPS 断崖下跌，调优需协同 buffer_pool_size、instances、old_blocks_pct 等参数。
缓冲池就是 InnoDB 的“热数据内存书架”
它不是简单的缓存，而是一块专用于缓存 InnoDB 数据页（16KB）、索引页、Undo 页和 Change Buffer 的连续内存区域。核心作用就两个：把频繁读的数据“捞上来”避免磁盘 IO；把待写的变更先“垫在内存里”，再批量刷盘。一次磁盘随机读要 0.1ms（SSD）甚至几 ms（HDD），而内存访问只要 100ns——快了 **1000 倍以上 **。所以缓冲池命中率掉到 95% 以下，QPS 往往断崖下跌。
为什么 innodb_buffer_pool_size 调不对，数据库就卡
这个参数设小了，大量请求被迫走磁盘，Innodb_buffer_pool_reads飙升；设大了又可能挤占 OS 内存，触发 OOM Killer 杀掉 mysql d 进程。更隐蔽的问题是：MySQL 5.7+ 虽支持在线调整，但若innodb_buffer_pool_instances 没配好（比如总大小 48GB 却只设 1 个 instance），所有线程争抢同一把 LRU 锁，CPU 软中断暴涨。
- 查当前真实压力：
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';算出命中率 =1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) - 物理内存≤16GB → 设为 50%；16–64GB → 60%；≥64GB → 70%，但必须预留至少 2GB 给 OS 和 binlog cache
- 超过 40GB 时，
innodb_buffer_pool_instances建议设为 8（不能超过实例数，否则无效）
SET GLOBAL动态调和重启改配置，哪个更危险
直接 SET GLOBAL innodb_buffer_pool_size=32G 看似方便，但 MySQL 会尝试一次性分配新内存块，若系统剩余内存不足，立刻报错 [ERROR] InnoDB: Cannot allocate memory for the buffer pool，且旧缓冲池不会自动释放——导致双倍 内存占用 ，极可能 OOM。相比之下，改my.cnf 后重启虽需停服，但内存是干净交接。真正安全的生产操作是用ALTER INSTANCE RESIZE BUFFER_POOL（MySQL 5.7.5+），它分批迁移页面，全程不锁表。
- 紧急测试可用
SET GLOBAL，但必须先free -m确认空闲内存 ≥ 新值 × 1.2 - 线上扩容优先选
ALTER INSTANCE，例如：ALTER INSTANCE RESIZE BUFFER_POOL TO 32G; - 切忌在业务高峰执行任何调整，哪怕只是
SHOW ENGINE INNODB STATUS也可能短暂阻塞
别只盯着大小，innodb_old_blocks_pct才是调优隐藏开关
缓冲池内部用改进型 LRU 管理，分为 young 区（高频热数据）和 old 区（刚加载 / 低频数据）。默认 old 区占 37%，但如果业务有定时全表扫描（比如报表 JOB），会把大量冷数据冲进 young 区，把真热数据顶出去——结果就是命中率暴跌。这时该调小innodb_old_blocks_pct（比如设为 20），并配合innodb_old_blocks_time=1000（毫秒），让新加载页在 old 区至少“冷静”1 秒才晋升，避免热数据被误淘汰。
- 查当前设置：
SELECT @@innodb_old_blocks_pct, @@innodb_old_blocks_time; - 仅对 OLTP 类高并发小查询有效；OLAP 类大扫描场景反而应增大
innodb_old_blocks_pct - 这个参数只能在启动时设置，修改后必须重启生效
缓冲池调优从来不是单点参数游戏，innodb_buffer_pool_size、instances、old_blocks_pct、flush_list刷新策略必须协同看——尤其当你的 Innodb_buffer_pool_pages_dirty 长期高于总页数的 70%，说明刷新跟不上写入，光调大缓冲池只会让问题更晚爆发。
