增大 innodb_buffer_pool_size 无明显效果是因 innodb_buffer_pool_instances 过小导致锁竞争——建议 ≥1GB 设为8、≥4GB 设为16，但不超过CPU核心数2倍，且需重启生效。
为什么增大 innodb_buffer_pool_size 没有明显效果？
因为缓冲池被单个实例锁竞争拖慢了——innodb_buffer_pool_instances 设得太小，甚至为 1。在高并发读写场景下，所有线程争抢同一组 LRU 和 chunk 链表锁，CPU 花在等待锁上，而不是真正做数据页操作。
实操建议：
- 先查当前值：
SHOW VARIABLES LIKE 'innodb_buffer_pool_instances'; - 若
innodb_buffer_pool_size≥ 1GB，innodb_buffer_pool_instances至少设为 8；≥ 4GB 可设 16；但不要超过 CPU 核心数的 2 倍（避免过度拆分带来管理开销） - 该参数只能在启动时生效，修改后必须重启 MySQL；线上重启前确认主从延迟、连接池重连策略
- 注意：MySQL 5.7 默认是 8，8.0 是 1（仅当 buffer pool
innodb_buffer_pool_instances 和 innodb_buffer_pool_size 怎么配比？
不是越大越好，也不是简单除法。每个 instance 独立维护自己的 free list、LRU list 和 flush list，但总 buffer pool 内存仍由 innodb_buffer_pool_size 统一分配。
常见错误现象：把 innodb_buffer_pool_instances 设成 64，但 innodb_buffer_pool_size 只有 2GB → 每个 instance 仅分到 ~32MB，反而加剧碎片和冷热页干扰。
实操建议：
- 保证每个 instance 分到至少 1GB（理想是 1–2GB），例如：buffer pool 设 16GB，则 instances 推荐 8 或 16
- 用
SHOW ENGINE INNODB STATUS\G查看Buffer pool size和Free buffers，再结合Per second averages calculated from the last 40 seconds下的Pages read/s、Pages created/s判断是否真缺内存，而非锁瓶颈 - 避免跨 NUMA 节点分配：若服务器是多路 CPU，用
numactl --interleave=all mysqld ...启动，否则某些 instance 可能始终访问远端内存
怎么验证 innodb_buffer_pool_instances 调优生效了？
不能只看命中率（Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads)），高负载下锁竞争会让这个指标“虚高”——请求排队等锁，看起来像缓存够用，实际吞吐掉下去了。
关键要看真实并发能力：
- 观察
SHOW STATUS LIKE 'Innodb_buffer_pool_wait_free';：非零说明有线程因没空闲页而等待，调大 instances 通常能压到 0 - 用
perf top -p $(pgrep mysqld)看是否还有大量buf_pool_mutex_enter或buf_LRU_get_free_block占 CPU - 对比 QPS 和平均响应时间：相同压力下，QPS 提升 + P95 延迟下降，才是有效优化
- 注意：如果
Threads_running长期 > 30，且Threads_connected波动剧烈，优先排查连接池或慢查询，别一上来就调 buffer pool
MySQL 8.0 下容易被忽略的兼容细节
8.0 默认把 innodb_buffer_pool_instances 锁死为 1（当 innodb_buffer_pool_size
另一个坑：innodb_buffer_pool_chunk_size 必须整除 innodb_buffer_pool_size / innodb_buffer_pool_instances，否则启动失败并报错：Invalid value for innodb_buffer_pool_chunk_size。
实操建议：
- MySQL 8.0+ 建议显式设置三者：
innodb_buffer_pool_size = 12Ginnodb_buffer_pool_instances = 12innodb_buffer_pool_chunk_size = 128M（12G ÷ 12 = 1G，1G ÷ 128M = 8，整除） - chunk_size 修改也需重启，且不能小于 1M，也不能大于 buffer pool 的 1/8
- 别信“自动适配”——8.0 的 auto-tune 只管 chunk count，不管 instances，这块必须人工对齐
innodb_buffer_pool_instances 看似只是改个数字，但它牵扯锁粒度、内存布局、NUMA 拓扑、甚至 MySQL 版本的默认行为差异。最容易被跳过的，是验证环节里那个 Innodb_buffer_pool_wait_free 计数器——它不响，不代表没问题；它一响，基本就是根子上的锁争用。 
