调大 innodb_buffer_pool_instances 反而变慢，因实例数超 CPU 核心数或 buffer pool 总大小会引发 mutex 争用和 false sharing；应 ≤ 物理核心数，常见取值 1/4/8，且每个 instance ≥1GB；需先确保 innodb_buffer_pool_size ≥ 热数据集大小，再微调 instances。
为什么调大 innodb_buffer_pool_instances 反而变慢了
不是值越大越好。当实例数超过 CPU 核心数，或远高于 buffer pool 总大小（比如 1GB pool 配 16 个 instance），会引发严重的 mutex 争用和 cache line false sharing，吞吐反而下降。
-
innodb_buffer_pool_instances应 ≤ 物理 CPU 核心数（非超线程数），常见取值为 1、4、8 - 每个 instance 最小建议 ≥ 1GB，否则拆分无意义；若
innodb_buffer_pool_size - MySQL 5.7+ 默认按 pool size 自动计算：≥ 1GB → 8，≥ 4GB → 16，但这个“自动”不考虑你的 CPU 架构和负载特征，得手动覆盖
怎么验证当前配置是否真起了作用
光看配置文件没用，得查运行时状态。关键指标不是“有没有分”，而是“分得匀不匀、锁得紧不紧”。
- 执行
SHOW ENGINE INNODB STATUS\G，搜Buffer pool size段，确认Instances数与配置一致 - 查
INFORMATION_SCHEMA.INNODB_BUFFER_POOL_STATS，对比各 instance 的PAGES_DATA和POOL_READS：若标准差 > 30%，说明访问严重倾斜，可能 hash 分布不均或 workload 集中在某几张表 - 监控
innodb_buffer_pool_wait_free：持续 > 0 表示 page clean 不及时，此时调 instance 无效，该优先调innodb_io_capacity或检查脏页刷盘瓶颈
和 innodb_buffer_pool_size 的配合关系
instance 是“分桶”，size 才是“总桶容积”。桶再多，水不够，照样干烧。
- 必须先确保
innodb_buffer_pool_size≥ 热数据集大小（通常为活跃表 + 索引的 1.2 倍），否则无论几个 instance，都在频繁换页 - 调整顺序严格为：先扩
size→ 观察命中率（innodb_buffer_pool_hit_rate≥ 99.5%）→ 再微调instances - 线上扩容
size可在线进行（MySQL 5.7+），但instances必须重启生效，别在高峰期改
容易被忽略的兼容性坑
有些旧应用或中间件会硬编码假设 buffer pool 是单实例，出问题不报错，只默默降级。
- Percona Toolkit 的
pt-online-schema-change在某些版本里，若检测到多个 buffer pool instance，会误判为“内存紧张”，强制降低 chunk 大小，拖慢 DDL - MySQL 5.6 不支持动态设置
innodb_buffer_pool_instances，且最大只允许 64；5.7+ 才支持 1024，但实际超过 16 就难有收益 - 使用 MGR 或 ProxySQL 的集群，需确保所有节点 instance 数一致，否则主从复制延迟可能因 page fault 模式差异而波动
真正卡并发的，往往不是 buffer pool 分不分，而是日志刷盘、自增锁、二级索引维护这些隐性瓶颈。调 innodb_buffer_pool_instances 前，先看 SHOW PROFILE 里 innodb_mutex_spin_waits 和 innodb_rwlock_sx_spins 是否异常高。
