升级MySQL8.0后为什么内存占用异常飙高-mysql教程-PHP中文网

MySQL 8.0升级后内存异常飙高主因是innodb_buffer_pool_size自动推导突变叠加performance_schema全量启用；需显式配置chunk_size与instances并关闭非必要P_S consumer。

升级mysql8.0后为什么内存占用异常飙高

MySQL 8.0 升级后内存异常飙高，90%以上情况不是 bug，而是两个默认行为突变叠加导致的：一是 innodb_buffer_pool_size 从固定小值（5.7 默认 128MB）变成按物理内存自动推算（如 64GB 机器默认分 48GB），二是 performance_schema 全量启用，光 events_statements_history_long 就预分配 128MB+ 内存——两者加起来轻松多占 500MB–数 GB RSS。

为什么 SHOW VARIABLES 显示的 innodb_buffer_pool_size 和实际 RSS 差一大截

你配置的 innodb_buffer_pool_size 只是“目标值”，InnoDB 实际分配时必须满足：innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances × 整数倍。MySQL 8.0.22+ 会自动推导 innodb_buffer_pool_chunk_size（比如 64GB 机器算出 256MB），若你没显式设死，就极易出现向上对齐现象。

常见表现：

SHOW VARIABLES LIKE 'innodb_buffer_pool_size' 返回 40GB，但 SHOW ENGINE INNODB STATUS\G 里 “Buffer pool size” 显示 5242880 × 16KB ≈ 80GB
启动日志出现 warning：“Buffer pool size rounded up to …”
SELECT @@innodb_buffer_pool_chunk_size, @@innodb_buffer_pool_instances, @@innodb_buffer_pool_size 结果无法整除

解决方法：在 /etc/my.cnf 的 [mysqld] 段显式写死：

innodb_buffer_pool_chunk_size = 128M
innodb_buffer_pool_instances = 4

确保 innodb_buffer_pool_size 能被 128 * 1024 * 1024 * 4 整除（例如设为 2G、4G、8G）。删掉旧的 ib_logfile0 和 ib_logfile1，否则可能启动失败。

为什么 performance_schema 一开就多占 300–500MB

MySQL 8.0 默认全量启用所有 instruments 和 consumers，其中 events_statements_history_long 和 events_transactions_history_long 这类长历史表，单个默认预分配 128MB+ 内存，且是启动即占——不查也吃。

验证方式：

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

SELECT * FROM performance_schema.memory_summary_global_by_event_name 
WHERE event_name LIKE 'memory/performance_schema/%' 
ORDER BY SUM_ALLOCATED DESC LIMIT 10;

实操建议：

关掉非调试用 consumer：UPDATE performance_schema.setup_consumers SET ENABLED = 'NO' WHERE NAME IN ('events_statements_history_long', 'events_transactions_history_long');
限制大小（写入 my.cnf）：performance_schema_events_statements_history_long_size = 10000（默认 20000）
禁用非核心 instruments（运行时生效）：UPDATE performance_schema.setup_instruments SET ENABLED = 'NO' WHERE NAME LIKE 'statement/sql/%' AND NAME NOT IN ('statement/sql/select','statement/sql/insert','statement/sql/update','statement/sql/delete');

为什么改了 my.cnf 却不生效

很多用户在宝塔里改了 /www/server/mysql/my.cnf，但 MySQL 8.0 启动时只认固定路径：/etc/my.cnf → /etc/mysql/my.cnf → /usr/etc/my.cnf → ~/.my.cnf。/www/server/mysql/my.cnf 不在默认列表里，除非显式加 --defaults-file 参数。

确认实际加载的配置：

ps aux | grep mysqld | grep -o '\-\-defaults-file=[^ ]*'

若无输出，说明走的是默认路径。最稳妥做法：

删掉或重命名 /etc/my.cnf（避免它覆盖你的配置）
确保 /www/server/mysql/my.cnf 顶部有 [mysqld] 段落
把所有关键参数（innodb_buffer_pool_size、performance_schema 相关项等）都放进去

真正容易被忽略的点是：buffer pool 预热和 P_S 内存都是“启动即占”，不是运行中缓慢增长；所以重启后几秒内 RSS 突增是正常行为，别误判为泄漏。调参后一定要看 SHOW ENGINE INNODB STATUS\G 和 performance_schema.memory_summary_global_by_event_name，而不是只信 SHOW VARIABLES。