innodb_buffer_pool_instances设为1更稳，因小内存下多实例会加剧地址空间碎片、触发低效管理逻辑并增加元数据开销；官方隐含建议是buffer_pool_size≤1GB时必须设为1。
innodb_buffer_pool_instances 本身不会直接导致 OOM，但它在低内存服务器上配错会放大 innodb_buffer_pool_size 的误用风险——尤其当 innodb_buffer_pool_size 被设得过大，而 innodb_buffer_pool_instances 又被设为默认值（如 8）时，MySQL 会尝试按实例数均分缓冲池，但底层内存分配仍需连续大块虚拟地址空间，反而加剧碎片和初始化失败概率。
为什么调小 innodb_buffer_pool_instances 反而可能更稳？
在 1GB 或 2GB 这类小内存 ECS 上，innodb_buffer_pool_size 实际只设到 384M–1G，远低于官方建议的“≥1GB 才启用多实例”。此时若保留默认 innodb_buffer_pool_instances=8：
- 每个 instance 分到的内存过小（如 384M ÷ 8 = 48M），触发 InnoDB 内部对极小 buffer pool 的低效管理逻辑
- 部分版本（如 MySQL 8.0.22+）在小 buffer pool + 多 instances 下，会额外增加 mutex 和元数据开销，反而推高常驻内存
- 日志中可能出现
InnoDB: Cannot allocate memory for the buffer pool，不是真没内存，而是 mmap 失败——小块多次申请比单块更易受地址空间碎片影响
该设成多少？看 innodb_buffer_pool_size 实际值
原则：只要 innodb_buffer_pool_size ≤ 1G，就强制设为 innodb_buffer_pool_instances=1。这是 MySQL 官方文档隐含的底线建议，也是生产环境验证过的安全值。
- 384M →
innodb_buffer_pool_instances=1 - 512M →
innodb_buffer_pool_instances=1 - 1G → 仍建议
=1；仅当升到 1.5G+ 且确认无其他服务争抢时，才考虑设为 2 - 绝对不要设为 0 或负数——MySQL 会静默回退到 1，但配置文件语义错误会误导后续维护
和 innodb_buffer_pool_size 的配合要点
innodb_buffer_pool_instances 是从属参数，必须和 innodb_buffer_pool_size 同步调整，否则失去意义：
- 先定
innodb_buffer_pool_size：1G 机器设 384M，2G 机器设 896M（不超过可用内存 50%） - 再定
innodb_buffer_pool_instances：上述值下一律用 1 - 重启后验证：执行
SHOW VARIABLES LIKE 'innodb_buffer_pool%';，确认innodb_buffer_pool_instances已生效，且innodb_buffer_pool_size没被自动修正（某些宝塔版本会强行重写） - 别碰
innodb_buffer_pool_chunk_size：小内存下保持默认（1M）即可，改它需要同时重算 chunk 数量，极易出错
真正容易被忽略的是：哪怕你把 innodb_buffer_pool_instances 设对了，如果 max_connections 还是默认 151，每个连接再配上 256K 的 sort_buffer_size，瞬时并发 50 个查询就能吃掉 12MB × 50 ≈ 600MB 额外内存——这比 buffer pool 本身还危险。调参必须看组合，不能只盯一个数字。
