mysql中的内存泄漏问题与解决策略_技术教程

MySQL RSS内存持续上涨通常由短连接滥用、查询缓存碎片或分配器行为导致，并非真正内存泄漏；应优先检查连接管理、禁用query_cache、调优wait_timeout等参数。

MySQL 进程 RSS 内存持续上涨但不释放

MySQL 本身不产生传统意义的“内存泄漏”，但常出现 mysqld 进程的 RSS 内存占用随时间持续增长，即使负载下降也不回落。这通常不是 C 级别堆内存未 free，而是内部缓存、连接状态或分配器行为导致的表象泄漏。

典型现象：ps aux --sort=-rss | grep mysqld 显示 RSS 持续上升，SHOW GLOBAL STATUS LIKE 'Threads_connected' 却稳定；重启后内存立即回落
最常见诱因：大量短连接未正确关闭（如 PHP-FPM 未设 mysqlnd.max_persistent=0）、应用端连接池配置不当、或启用了未调优的查询缓存（query_cache_type=1）
InnoDB 缓冲池（innodb_buffer_pool_size）本身是预分配且长期驻留的，不属于泄漏——但若设置过大（如超过物理内存 70%），会挤压系统页缓存，引发 swap 和 OOM Killer 干预，看起来像“泄漏”

如何定位真实内存增长源头

靠 ps 或 top 只能看到进程总 RSS，无法区分是 InnoDB

、线程栈、还是 per-connection buffers 在涨。必须结合 MySQL 内部指标和 OS 层分析。

检查活跃连接的内存开销：

SELECT 
  THREAD_ID, 
  PROCESSLIST_USER, 
  PROCESSLIST_HOST, 
  CURRENT_NUMBER_OF_BYTES_USED 
FROM performance_schema.threads t 
JOIN performance_schema.memory_summary_by_thread_by_event_name m 
  ON t.THREAD_ID = m.THREAD_ID 
WHERE m.CURRENT_NUMBER_OF_BYTES_USED > 1024*1024*50 
ORDER BY m.CURRENT_NUMBER_OF_BYTES_USED DESC 
LIMIT 10;

确认是否为线程级累积：对比 Threads_connected 与 Threads_created，若后者远大于前者（比如每小时新增数千），说明连接复用失败，每个新连接都带一份 sort_buffer_size、read_buffer_size 等副本
检查 glibc malloc 行为：在 Linux 上运行 cat /proc/$(pgrep mysqld)/smaps | awk '/^Size:/ {sum+=$2} END {print sum}'，再对比 malloc_stats() 输出（需开启 --malloc-lib=tcmalloc 或使用 gdb -p $(pgrep mysqld) -ex "call malloc_stats()" -ex quit）可判断是否是分配器碎片

关键参数与连接管理避坑点

多数“内存泄漏感”来自配置与使用方式失配，而非 MySQL 自身缺陷。以下参数直接影响内存驻留行为：

wait_timeout 和 interactive_timeout 必须设为合理值（如 300），否则空闲连接长期持有内存；注意 JDBC 默认不传 sessionVariables=wait_timeout=300，需显式配置
max_connections 不宜盲目调大，每个连接至少消耗 ~256KB 基础内存（不含排序/临时表），超量会导致 table_open_cache 和 thread_cache_size 失效，加剧分配压力
禁用已废弃的 query_cache_type（MySQL 8.0 已移除），5.7 中若启用且 query_cache_size > 0，其碎片化严重，且无法被其他模块回收
避免在存储过程中大量使用 CREATE TEMPORARY TABLE，尤其配合大结果集；临时表默认走内存引擎，但超出 tmp_table_size 和 max_heap_table_size 后会落磁盘，而元数据和锁结构仍驻留内存

何时该怀疑是真正的内存问题

如果已排除连接滥用、缓存配置、分配器碎片，并满足以下全部条件，才需深入排查 MySQL 源码或报告 bug：

RSS 持续增长速率与 QPS/TPS 无明显相关性（例如低峰期仍在涨）
SHOW ENGINE INNODB STATUS 中 ROW OPERATIONS 部分显示 history list length 异常高（> 1M），且 purge done 停滞，可能因长事务阻塞 purge 线程，间接导致 undo log 内存不释放
使用 Valgrind + --tool=memcheck --leak-check=full 编译调试版 MySQL，在可控负载下运行数小时，确有 definitely lost 报告（极罕见，多见于自定义 UDF 或插件）
升级到最新 GA 版本（如 8.0.33+ 或 8.4.0+）后问题消失，说明是已修复的已知问题（例如早期 5.7 中 performance_schema 的 memory instrumentation 泄漏）