缓冲池是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杀掉mysqld进程。更隐蔽的问题是：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%，说明刷新跟不上写入，光调大缓冲池只会让问题更晚爆发。
