MySQL 8.0内存飙升主因有四：①buffer pool关机dump/启动预热导致RSS陡增；②performance_schema全开占用数百MB；③buffer_pool_size未随硬件升级调整；④5.7升级残留query_cache配置引发内存碎片。
MySQL 8.0 默认启用 innodb_buffer_pool_dump_at_shutdown 导致启动后内存飙升
MySQL 8.0 启动时会自动加载上次关闭前保存的 ib_buffer_pool 文件（默认路径：./ib_buffer_pool），如果该文件记录了大量页，InnoDB 会在后台线程中快速预热，表现为启动后几秒内 RSS 内存陡增 —— 这不是泄漏，是预热行为，但容易被误判为异常。
实操建议：
- 确认是否启用该机制：
SHOW VARIABLES LIKE 'innodb_buffer_pool_dump_at_shutdown';和innodb_buffer_pool_load_at_startup，两者默认均为ON - 若实例重启频繁、且 buffer pool 不需要“冷启动即满载”，可关掉预热：
SET GLOBAL innodb_buffer_pool_load_at_startup = OFF;，并写入配置文件禁用 - 检查
ib_buffer_pool文件大小，若远超实际常用数据量（比如 1GB buffer pool 对应 800MB 的 dump 文件），说明 dump 范围过宽，可调小innodb_buffer_pool_dump_pct（默认 25，即只 dump 25% 最热页）
performance_schema 默认全开吃掉几百 MB 内存
MySQL 8.0 中 performance_schema 默认启用全部 instrument 和 consumer，尤其 events_statements_history_long、events_transactions_history_long 等长历史表，默认分配大内存（单表可达 128MB+），总内存占用常被忽略。
实操建议：
- 查当前 P_S 内存使用：
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），同理调整其他_size参数
innodb_buffer_pool_size 设置未随物理内存增长同步调整
升级 MySQL 8.0 常伴随服务器硬件升级（如从 32G 到 64G），但配置仍沿用旧 my.cnf，导致 innodb_buffer_pool_size 过小 → InnoDB 频繁淘汰页 → 查询变慢 → DBA 误以为“新版本更耗资源”，于是盲目调大 buffer pool，反而引发 swap 或 OOM。
实操建议：
- 8.0 推荐值仍是物理内存的 50%–75%，但必须结合实际工作集：用
SELECT (SELECT COUNT(*) FROM information_schema.INNODB_BUFFER_PAGE) * 16384 / 1024 / 1024 AS used_mb;估算活跃页占用（单位 MB） - 避免直接设为 75%：若机器跑多实例或有 Java 应用共存，需预留至少 4–8GB 给 OS + 其他进程
- 动态调整安全：8.0 支持在线调大 buffer pool（
SET GLOBAL innodb_buffer_pool_size = 3221225472;），但仅支持按 chunk（默认 128MB）对齐，且不能小于当前已分配最小 chunk
查询缓存关闭后，query_cache_type=1 仍残留内存碎片
MySQL 8.0 已彻底移除查询缓存（QC），但若从 5.7 升级而来，配置中残留 query_cache_type = 1 或 query_cache_size > 0，mysqld 启动时仍会尝试初始化 QC 相关结构，虽不生效，却可能造成内存分配器行为异常，加剧 malloc 层碎片。
实操建议：
- 升级后务必清理所有 QC 相关配置项：
query_cache_type、query_cache_size、query_cache_limit，整行删掉或注释 - 确认无残留：
SHOW VARIABLES LIKE 'query%';应返回空结果集 - 若发现
malloc分配延迟高或vmstat显示大量 minor page fault，可搭配pt-mysql-summary检查内存分配模式，排除 QC 遗留干扰
真正棘手的从来不是某个参数，而是多个机制叠加作用：buffer pool 预热 + P_S 历史表 + 旧配置残留，三者同时存在时，内存增长曲线会非常不线性。上线前最好用 mysqltuner.pl 扫一遍，再比对 /proc/PID/status 的 VmRSS 和 MemAvailable 余量。
