innodb_buffer_pool_size不是越大越好，而是需平衡热点数据缓存与系统内存预留；80%是上限红线而非推荐值。查命中率用SHOW ENGINE INNODB STATUS\G，公式为(1−innodb_buffer_pool_reads/innodb_buffer_pool_read_requests)×100%，低于95%需调大，高于99.5%再调大收益低且易挤占内存；同时监控innodb_buffer_pool_pages_free是否持续为0、innodb_buffer_pool_wait_free是否大于0及free -h可用内存。
直接给结论：innodb_buffer_pool_size 不是越大越好，而是要卡在“足够缓存热点数据 + 预留系统内存”之间的平衡点；80% 是上限红线，不是推荐值。
怎么看当前缓冲池是否够用
别猜，用 SHOW ENGINE INNODB STATUS\G 查真实命中率。核心公式是：
命中率 = (1 − innodb_buffer_pool_reads / innodb_buffer_pool_read_requests) × 100%
如果低于 95%，说明磁盘读太多，大概率需要调大；高于 99.5%，再调大收益极低，还可能挤占系统内存。
补充监控项：
• innodb_buffer_pool_pages_free 持续为 0？说明已满，但不等于够用（可能频繁淘汰）
• innodb_buffer_pool_wait_free > 0？说明有线程在等空闲页，必须扩容或优化查询
• free -h 显示可用内存
怎么设具体数值（按物理内存分档）
所有配置基于 Linux 下 /etc/my.cnf 的 [mysqld] 节点，且假设 MySQL 是专用服务（非混部）：
- ≤ 4G 内存：设为
2g（50%），不建议更高 - 8G 内存：设为
5g～6g（60%～75%），优先选5g - 16G 内存：设为
10g～12g（60%～75%），避开11g这类非 chunk 对齐值 - 32G+ 内存：设为 70%～80%，但必须满足
innodb_buffer_pool_size是innodb_buffer_pool_chunk_size×innodb_buffer_pool_instances的整数倍（默认 chunk 是 128M，instance 建议设 8 或 16）
例如 32G 内存：
• 错误写法：innodb_buffer_pool_size = 24g（24G ÷ 128M = 192，不是 8 或 16 的倍数）
• 正确写法：innodb_buffer_pool_instances = 16 + innodb_buffer_pool_size = 24576m（24G = 192 × 128M，192 ÷ 16 = 12，对齐）
动态调整时最容易踩的坑
MySQL 5.7+ 支持在线调大 innodb_buffer_pool_size，但以下情况会失败或埋雷：
- 新值不是 chunk 对齐的倍数 → MySQL 自动向下取整到最近合法值，你根本没设成功
- 没同步调
innodb_buffer_pool_instances→ 实例数太少，高并发下内部锁竞争反而升高（SHOW ENGINE INNODB STATUS里看 “Mutex spin waits” 异常高） - 调大后没观察
vmstat 1的si/so（swap in/out）→ 出现非零值就是系统开始 swap，性能断崖下跌 - 以为调大就万事大吉 → 忽略了
sort_buffer_size、tmp_table_size等会话级参数的叠加效应；100 个连接 × 4Msort_buffer_size= 400M 额外内存，没算进去就容易 OOM
最常被忽略的一点：缓冲池大小变更后，MySQL 不会自动把旧数据页刷进新分配的区域，冷启动期间性能会阶段性回落。生产环境务必配合 innodb_buffer_pool_dump_at_shutdown=ON 和 innodb_buffer_pool_load_at_startup=ON，否则重启等于重头开始缓存预热。
