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 泄漏）
真正由 MySQL Server 层代码引起的内存泄漏极少，绝大多数场景只需收紧连接生命周期、关闭过时功能、并监控 performance_schema.memory_summary_* 视图即可收敛。别一上来就怀疑源码——先查应用怎么连的。
