mysql 8.0升级后内存“翻倍”主因是innodb_buffer_pool_size自动向上对齐与performance_schema长历史表预分配叠加；调优二者可压降90%异常rss增长。
MySQL 8.0 升级后内存“翻倍”基本不是 bug，而是两个默认行为突变叠加导致的：一是 innodb_buffer_pool_size 启动时自动按物理内存推算并向上对齐，二是 performance_schema 全量启用长历史表预分配内存。调这两个，90% 的异常 RSS 增长就压下来了。
为什么 innodb_buffer_pool_size 显示值和实际 RSS 差一大截
你看到 SHOW VARIABLES LIKE 'innodb_buffer_pool_size' 返回 40GB，但 ps aux 里 mysqld 的 RSS 达到 72GB——这通常是因为 InnoDB 实际分配被向上对齐了。
MySQL 8.0.22+ 会自动推导 innodb_buffer_pool_chunk_size（比如 64GB 机器算出 256MB），再乘以 innodb_buffer_pool_instances（默认 8），最终分配 = chunk_size × instances × chunk_count。而你配置的 innodb_buffer_pool_size 只是“目标值”，InnoDB 必须满足总大小能被 chunk_size × instances 整除；不满足就悄悄向上补齐。
启动日志里如果出现 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（必须是 1M 整数倍）
- 同步设 innodb_buffer_pool_instances，确保 innodb_buffer_pool_size / (128 * 1024 * 1024 * innodb_buffer_pool_instances) 是整数（例如 innodb_buffer_pool_size = 2G，instances 设 2、4 或 8）
- 删除旧的 ib_logfile0 和 ib_logfile1（路径通常为 /www/server/data/ 或 /var/lib/mysql/），否则启动报错
为什么 performance_schema 一开就多占 300–500MB
这不是错觉。MySQL 8.0 默认全量启用所有 instruments 和 consumers，其中 events_statements_history_long 和 events_transactions_history_long 这类长历史表，单个默认预分配 128MB+ 内存，且启动即占——查不查都吃。
常见错误现象：
- mysqld 进程 RSS 突然多出 300–500MB
- SHOW PROCESSLIST 看不到异常连接，但 sys.memory_global_total 显示 performance_schema 占比超 40%
实操建议：
- 查真实占用：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）
- 注意配置文件路径：宝塔用户常改 /www/server/mysql/my.cnf，但 MySQL 默认只认 /etc/my.cnf → 确认实际加载的配置：ps aux | grep mysqld | grep -o '\-\-defaults-file=[^ ]*'；若无输出，说明走默认路径
别漏掉 innodb_buffer_pool_load_at_startup 和 temptable_max_ram
这两个容易被忽略，但对启动瞬间内存飙升影响极大：
innodb_buffer_pool_load_at_startup 默认为 ON，MySQL 启动时会加载上次保存的 ib_buffer_pool 文件（默认在数据目录），后台线程快速预热，表现为几秒内 RSS 陡增。若实例重启频繁、且不需要冷启动即满载，可关掉：
- 运行时：SET GLOBAL innodb_buffer_pool_load_at_startup = OFF;
- 配置文件加：innodb_buffer_pool_load_at_startup = OFF
temptable_max_ram 控制 TEMPTABLE 引擎的总内存池上限，默认是物理内存的 3%（上限 4 GiB）。它不支持运行时设置，必须写进配置文件：
- temptable_max_ram = 4G（MySQL 8.0.23+ 支持单位，旧版写 4294967296）
- 同时确保 tmp_table_size 和 max_heap_table_size 显式设成完全相等（如都为 256M），否则老式 MEMORY 临时表逻辑仍可能落盘
真正难调的是协同关系：buffer pool 大小、chunk_size、instances、P_S history size、temptable_max_ram —— 改一个不联动其他，很容易白忙活。最稳妥的做法是先停服务，删掉 ib_buffer_pool 和 ibtmp1，再按新配置重启。
