缓冲池是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+），它分批迁移页面，全程不锁表。
