mysql 5.7+在线调整innodb_buffer_pool_size未生效，是因实际分配需满足chunk_size×instances×n，非整数倍时自动向上取整，导致内存超配甚至oom。
SET GLOBAL innodb_buffer_pool_size 为什么设了却没生效
你执行 SET GLOBAL innodb_buffer_pool_size = '2G' 后查 SELECT @@innodb_buffer_pool_size，发现返回值是 2147483648（2GB），但 ps aux 看 mysqld 进程 RSS 内存飙到 3.5GB 甚至触发 OOM killer —— 这不是 MySQL 撒谎，而是它“悄悄加量”了。
根本原因是：MySQL 5.7.5+ 的 buffer pool 按 chunk 管理，实际分配必须满足：innodb_buffer_pool_size = innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances × N（N 为正整数）。
- 默认
innodb_buffer_pool_chunk_size = 128M，innodb_buffer_pool_instances = 8→ 最小粒度 = 1024MB - 你设
1500M，系统自动向上取整到2048M（2×1024） - 在 2GB 虚机上，这直接导致内存超配，
dmesg -T | grep mysqld会看到 “Killed process mysqld”
在线调整前必须验证的三个数值
别信配置文件或 SET 命令返回 OK，必须手动确认三者是否对齐。否则调整就是往 OOM 边缘试探。
- 先查当前值：
SHOW VARIABLES LIKE 'innodb_buffer_pool%'; - 算出最小粒度：
SELECT @@innodb_buffer_pool_chunk_size * @@innodb_buffer_pool_instances; - 你要设的目标值，必须是该结果的整数倍；如果不是，手动向上取整（例如粒度 1024M，目标 1800M → 改设
'2G'或2147483648） - 执行后立刻验证：
SELECT @@innodb_buffer_pool_size;，别只看命令返回“Query OK”
调整过程中 buffer pool 真的“在线”吗
所谓“在线”，是指不用重启 mysqld，但不等于无感知。后台线程 buf_resize_thread 在搬数据页，期间 buffer pool 会短暂锁住：
- 所有新请求可能被阻塞几十毫秒到数秒，取决于要移动的 page 数量
- 可通过
SHOW STATUS LIKE 'Innodb_buffer_pool_resize_status';实时观察，常见状态如：Resizing buffer pool. Completed 123456789 / 234567890 pages. - 收缩比扩容更危险：若待删 chunk 中有未提交事务占用的脏页，会反复重试并打印 warning 到 error log，阻塞时间拉长
- 高并发写入场景下，建议避开业务高峰，且提前检查
INFORMATION_SCHEMA.INNODB_TRX中是否有运行超 60 秒的长事务
宝塔/小内存 VPS 上最常踩的组合坑
在 4GB 宝塔服务器上，很多人照搬“设 70%”设成 innodb_buffer_pool_size = 3G，结果隔几小时就被 OOM kill —— 这不是 MySQL 的错，是没扣掉宝塔全家桶（bt、nginx、php-fpm）和系统基础开销。
- 4GB 机器安全上限建议 ≤
2.2G；2GB VPS 直接设死512M，别套比例 - 必须关掉隐形内存大户：
innodb_buffer_pool_dump_at_shutdown = OFF和innodb_buffer_pool_load_at_startup = OFF（宝塔默认开，重启时 dump/load 全量 buffer pool，极易触发内存尖峰） - 混部环境还要同步调低
wait_timeout（建议 300）和innodb_lock_wait_timeout（建议 10–20），防止空闲连接长期持锁占内存 - 改完配置必须用
service mysqld restart（宝塔里systemctl restart mysqld可能不生效）
真正危险的从来不是“调不了”，而是“调了但不知道它偷偷变了”。chunk 对齐、实例启用阈值、宝塔进程争抢、OOM 日志验证——漏掉任意一环，动态调整就从优化手段变成宕机导火索。
