innodb_buffer_pool_instances设了不生效是因为MySQL 5.7强制要求innodb_buffer_pool_size≥1GB（1073741824字节），否则自动降为1；同时size必须是chunk_size×instances的整数倍，否则向上取整调整。
必须先确保 innodb_buffer_pool_size ≥ 1GB，否则无论你怎么设 innodb_buffer_pool_instances，MySQL 启动时都会静默降为 1。
为什么 innodb_buffer_pool_instances 设了却不生效？
这不是配置遗漏，是 MySQL 5.7 的硬性阈值限制：源码里强制检查 innodb_buffer_pool_size 是否 ≥ 1073741824（即 1GB）。低于该值，哪怕你写 innodb_buffer_pool_instances = 16，日志里也会出现：
[Warning] InnoDB: Using default value 1 for innodb_buffer_pool_instances.
验证方式只有两条 SQL：
-
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';—— 确认返回值 ≥ 1073741824 -
SHOW VARIABLES LIKE 'innodb_buffer_pool_instances';—— 确认返回值是你配置的数字，不是 1
怎么选 innodb_buffer_pool_instances 的值？
它本质是把总 buffer pool 拆成 N 个独立加锁的子池，目标是降低高并发下的 mutex 争用。但不是越多越好，关键看两个硬约束：
- 每个 instance 至少要分到 1MB：即
innodb_buffer_pool_size / innodb_buffer_pool_instances ≥ 1048576 - 建议值 ≈ CPU 逻辑核数，且 ≤ 64；例如 24 核服务器，可试
innodb_buffer_pool_instances = 24 - 若
SHOW ENGINE INNODB STATUS\G中频繁看到BUF_POOL_WAIT_FREE或大量log writes pending，说明当前分片粒度太粗，可适当增加
innodb_buffer_pool_instances 和 innodb_buffer_pool_chunk_size 怎么配合？
chunk 是内存分配单位，默认 128MB；多个 instance 的 chunk 是轮询分配的。两者必须满足：
-
innodb_buffer_pool_size必须是(innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances)的整数倍，否则 MySQL 会向上取整 —— 比如设了 9G + 16 instances，实际生效可能是 10G -
innodb_buffer_pool_chunk_size只能在启动前修改；且修改后需满足：innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances ≤ innodb_buffer_pool_size - 不建议手动调小 chunk（如设成 1MB）：会导致初始化慢、内存碎片多、管理开销上升
在线调整 innodb_buffer_pool_size 会影响 innodb_buffer_pool_instances 吗？
会，而且风险不小。动态调整 size 时：
- MySQL 会先将 buffer pool 整体清空（所有页刷盘或丢弃），再按新大小重建 —— 这期间缓存全失效，QPS 可能骤降
- 如果新 size 低于 1GB，
innodb_buffer_pool_instances会被重置为 1（即使配置文件里没改） - 官方不推荐纯在线扩缩容；更稳妥的做法是：停写 → 优雅重启 → 验证变量值 → 恢复流量
真正容易被忽略的是 chunk 对齐规则和 size 下限的双重绑定——很多人调完 instances 发现没效果，第一反应是参数没加载，其实根本原因是 size 卡在了 999MB 这种“差一点点”的位置。
