命中率低的直接原因是innodb_buffer_pool_size过小；当innodb_buffer_pool_reads占比超1%或命中率低于95%，说明存在i/o瓶颈；设置值须为chunk×instances整数倍，且动态调整会自动向下取整；需避开wait_free高峰期操作，并合理配置instances防锁竞争。
命中率低的直接原因往往是 innodb_buffer_pool_size 设置过小
如果你看到 Innodb_buffer_pool_reads 占 Innodb_buffer_pool_read_requests 比例超过 1%，基本可以断定缓冲池不够用。命中率低于 95% 就该动手调了——这不是“可能优化”，而是当前已存在明显 I/O 瓶颈。
设置值必须满足 chunk × instances 的整数倍约束
MySQL 5.7+ 动态调整时不会直接按你输入的值生效，而是自动向下取整到最接近的合法值。这个合法值由公式决定：innodb_buffer_pool_size = innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances。
常见踩坑点：
-
innodb_buffer_pool_chunk_size默认是128M，不能动态修改，改它必须重启 - 若
innodb_buffer_pool_instances设为8，那最小可设缓冲池就是1024M（8 × 128M），设1G会自动变成1024M；设1.5G则被截断为1024M，不是你想要的1536M - 想设
6G缓冲池？得确保6G ÷ instances是128M的整数倍，比如instances=6→6G ÷ 6 = 1G = 8 × 128M，合法；instances=4→6G ÷ 4 = 1.5G = 12 × 128M，也合法
动态调整时要避开 innodb_buffer_pool_wait_free 高峰
执行 SET GLOBAL innodb_buffer_pool_size = ... 后，InnoDB 会分 chunk 逐步扩容或缩容。期间若并发请求频繁申请新页，而 Free List 不足，就会卡在 innodb_buffer_pool_wait_free 等待上——表现为短暂但明显的查询延迟飙升。
安全操作建议：
- 选业务低峰期操作，避免在主从同步压力大或批量导入时调整
- 一次调整幅度建议 ≤ 总内存的 10%，例如 64GB 机器，单次增减不超过 6GB
- 调整后立刻查
SHOW ENGINE INNODB STATUS\G，翻到 BUFFER POOL AND MEMORY 小节，确认Free buffers和Database pages数值稳定上升/下降，且Pages made young无异常突增
命中率达标后仍要防实例锁竞争
当 innodb_buffer_pool_size 超过 24GB，不配 innodb_buffer_pool_instances 就等于把所有线程往一个全局锁里塞。实测中，32GB 缓冲池配 instances=1 时，innodb_buffer_pool_mutex_spin_waits 可能高达每秒上千次。
推荐配置组合：
- ≤ 16GB 内存：保持默认
instances=1即可 - 16–64GB：设
instances=4或8，确保每个 instance ≥ 1GB - ≥ 64GB：用公式
instances = MIN(CEIL(buffer_pool_size / 1073741824), 8)，即按每 GB 一个 instance，上限 8
真正容易被忽略的是：调大 buffer pool 后，innodb_buffer_pool_instances 必须同步设对，否则你省下的磁盘 I/O 全被 mutex 争用吃掉了。
