MySQL升级后innodb_buffer_pool_size暴增，因8.0+默认按物理内存自动计算（如64GB机器分48GB），而5.7及以前用保守固定默认值（8MB–128MB）；需在配置文件中显式设定合理值，并同步调低max_connections等参数防OOM。
MySQL 升级后内存暴增，大概率不是 bug，而是 innodb_buffer_pool_size 默认行为变了——5.7 以前不设就用默认值（小），8.0+ 不设会按物理内存自动推算（大），一升级就吃光内存。
为什么升级后 innodb_buffer_pool_size 突然飙高
MySQL 5.7 及更早版本：若配置文件里没写 innodb_buffer_pool_size，启动时用硬编码默认值（通常 8MB 或 128MB），很保守；
MySQL 8.0+：默认启用自动计算逻辑，公式类似 min(总内存 × 0.75, 12G)，一台 64GB 机器可能直接分走 48GB，远超你旧版习惯的配置。
常见表现：
• ps aux 看 mysqld 进程 RSS 比升级前翻倍甚至更多
• dmesg | grep -i "kill process.*mysqld" 出现 OOM Killer 日志
• SHOW VARIABLES LIKE 'innodb_buffer_pool_size' 返回值远高于你预期（比如显示 42949672960，即 40GB）
检查方式：
• 连上 MySQL 执行 SELECT @@innodb_buffer_pool_size / 1024 / 1024 AS mb;
• 对照你的物理内存（free -h），看是否超过 70% 且没给系统和其他服务留余量
怎么安全地重设 innodb_buffer_pool_size
不能只改一个参数就重启，必须同步控制“每连接内存”和“实例级放大效应”：
- 先在配置文件（
/etc/my.cnf或/www/server/mysql/etc/my.cnf）的[mysqld]段明确写死该值，例如：innodb_buffer_pool_size = 2G（注意：MySQL 5.7+ 支持G，但别写2048M，部分旧补丁有解析问题） - 顺手调低
max_connections（比如从 1000 改成 200），否则每个连接的sort_buffer_size、join_buffer_size叠加起来照样爆内存 - 如果用了大量触发器或存储过程（尤其在从库），把
table_open_cache_instances设为1—— 默认是 16，多实例缓存会让大触发器内存占用翻倍 - 删掉已弃用的
query_cache_type和query_cache_size（MySQL 8.0 已移除，5.7 若启用也会抢内存）
在线调整失败的典型原因
执行 SET GLOBAL innodb_buffer_pool_size = 2*1024*1024*1024; 报错或没生效？常见卡点：
- 新值不是
innodb_buffer_pool_chunk_size的整数倍（默认 128MB，所以 2G 必须是 128MB × 整数 → 2G ÷ 128MB = 16，合法；但 1.5G 就非法，会被向下取整到 1.40625G） -
innodb_buffer_pool_instances小于 1（必须 ≥1，且建议 ≥ CPU 核数，但小内存机器可设为 1） - 当前 buffer pool 正在被大量线程使用，MySQL 拒绝在线收缩（只能扩不能缩，除非你先杀掉活跃连接）
- 配置文件里仍存在旧值，重启后覆盖了 SET 的临时值
宝塔面板用户特别注意
宝塔的【配置修改】界面有时会偷偷补全缺失参数，导致你没写的项被填上危险默认值。务必手动检查生成的配置文件：
- 打开
/www/server/mysql/etc/my.cnf，确认只有你明确写的innodb_buffer_pool_size行，没有隐藏的 auto-generated 块 - 如果用的是低配机器（≤4GB 内存），别信面板推荐值——它常按“通用模板”给 1G，实际应压到 512MB 甚至更低
- 改完点【重启 MySQL】前，先在终端执行
mysqld --defaults-file=/www/server/mysql/etc/my.cnf --validate-config，验证语法无误再重启
真正棘手的从来不是 buffer pool 本身，而是它和 max_connections、table_open_cache_instances、触发器规模这三者的乘积效应。一个参数调对了，另外三个没动，照样 OOM。
