innodb缓冲池大小应设为物理内存的50%–75%，需预留系统、其他mysql组件及业务进程内存；可在线动态调整（mysql 5.7+），但须满足chunk_size×instances整数倍；命中率应≥95%，通过逻辑读与物理读比值计算，低于90%需扩容或优化索引。
innodb_buffer_pool_size 设置多大才合适
这个值直接决定 InnoDB 能缓存多少数据和索引，设太小会导致频繁磁盘读，设太大可能挤占系统内存引发 swap。生产环境通常设为物理内存的 50%–75%，但必须留足空间给 OS、MySQL 其他缓冲区（如 key_buffer_size、连接线程栈）和业务进程。
- 查可用内存：
free -h或cat /proc/meminfo | grep MemAvailable - 若服务器独占 MySQL，16GB 内存可设
innodb_buffer_pool_size = 12G - 若跑着 Redis、Java 应用等，建议压到 8–10G，并观察
Innodb_buffer_pool_wait_free是否持续增长 - 不能超过
innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的整数倍（否则启动报错Buffer pool size can't be set）
如何在线调整 innodb_buffer_pool_size（MySQL 5.7+）
5.7 开始支持动态调整，但有前提：必须启用 innodb_buffer_pool_chunk_size，且新值需是 chunk_size × instances 的整数倍。调整过程会分 chunk 释放/分配，不锁整个 buffer pool。
- 先查当前配置：
SELECT @@innodb_buffer_pool_size, @@innodb_buffer_pool_chunk_size, @@innodb_buffer_pool_instances; - 假设结果是 8589934592（8G）、134217728（128MB）、8，则最小调整单位是
134217728 * 8 = 1073741824（1G） - 在线设为 10G：
SET GLOBAL innodb_buffer_pool_size = 10737418240; - 注意：该命令只改运行时，重启失效，必须同步写入
my.cnf的[mysqld]段
检查缓冲池命中率是否健康
别只盯着 innodb_buffer_pool_hit_rate 看百分比，MySQL 5.7+ 的 Performance Schema 提供更准的指标：innodb_buffer_pool_read_requests（逻辑读）与 innodb_buffer_pool_reads（物理读）之比才是真实命中率。
- 计算公式：
(Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests - 低于 95% 就该警惕；低于 90% 通常说明 buffer pool 不够或查询未走索引
- 查实时值：
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_%read%'; - 命中率高但响应慢？可能是
innodb_buffer_pool_wait_free非零，说明脏页刷盘跟不上，需调大innodb_io_capacity或优化写负载
为什么加了 buffer pool 还是慢？几个关键漏点
缓冲池只是调优一环，常见“加了没用”的原因往往在别处：
- 表没主键或全是全表扫描：InnoDB 必须回表，buffer pool 缓存的是页不是行，无效缓存拉低命中率
-
innodb_flush_method设成fsync（默认）在机械盘上写放大严重，SSD 可试O_DIRECT - 大量短连接导致
thread_cache_size不足，频繁创建销毁线程消耗 CPU，掩盖了 buffer pool 效果 - 查询用了
SQL_NO_CACHE或开启了query_cache_type=1（已废弃），反而干扰执行计划 - buffer pool 分实例数（
innodb_buffer_pool_instances）设太高（如 > 8），在小内存下增加管理开销，反而降低效率
实际调优时，innodb_buffer_pool_size 是起点，不是终点。真正卡顿的根因，常藏在慢查询日志、EXPLAIN 输出、以及 information_schema.INNODB_METRICS 的细粒度计数里。
