在MySQL中如何避免长连接导致的内存暴涨问题-mysql教程-PHP中文网

长连接导致mysqld RSS内存持续上涨，主因是未清理临时表、用户变量和预处理语句等会话资源，这些绑定连接生命周期且MySQL不主动释放；需应用层在连接归还池前执行SET @var=NULL、DROP TEMPORARY TABLE、mysql_reset_connection()等清理操作，并合理配置连接池maxLifetime与wait_timeout避免连接失效雪崩。

在mysql中如何避免长连接导致的内存暴涨问题

别指望 wait_timeout 自动救场，它只杀空闲连接，不清理已分配的内存；真正要防的是连接复用时残留的会话状态——临时表、用户变量、预处理语句这些资源 MySQL 不会在连接重用时自动清空。

为什么长连接会让 mysqld RSS 内存持续上涨

长连接本身不是问题，问题是连接没断，但内部状态越积越多：一个未 DROP 的 CREATE TEMPORARY TABLE 会一直占内存和磁盘；@blob := LOAD_FILE('/huge') 这类大对象赋值后不显式置空，就卡在会话里；PREPARE stmt FROM 后忘了 DEALLOCATE PREPARE，每个预处理语句都吃几百字节。这些资源绑定连接生命周期，MySQL 不主动释放，直到连接断开——而连接池偏偏不让它断。

表现就是：SHOW PROCESSLIST 里一堆 Sleep 连接，innodb_buffer_pool_pages_total 缓慢爬升，ps aux --sort=-rss | grep mysqld 看到 RSS 持续增长，且远超 innodb_buffer_pool_size + sort_buffer_size * max_connections 的理论总和。

连接归还池前必须执行的三件事

不能只靠服务端 timeout，得在应用层主动“擦屁股”。HikariCP、Druid 等主流连接池支持归还前执行自定义 SQL，这是最可控的清理时机：

显式清空用户变量：SET @var = NULL; SET @another = NULL;（可批量写成一行）
删掉业务层明确创建的临时表：DROP TEMPORARY TABLE IF EXISTS tmp_user_batch;（需业务代码记录表名）
调用 mysql_reset_connection()（MySQL 5.7.3+ / Connector/J 8.0.14+）——它比单纯 RESET QUERY CACHE（已弃用）有效得多，能重置会话级所有状态，包括字符集、SQL mode、用户变量、临时表、预处理语句等

HikariCP 配置必须错开 MySQL 的 wait_timeout

如果连接池的 maxLifetime 和 idleTimeout 都大于 MySQL 的 wait_timeout（默认 28800 秒），就会出现“连接池以为连接还活，MySQL 却已悄悄 KILL”，导致后续请求抛 Communications link failure 或 Connection reset。

生产环境建议：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

MySQL 端设 wait_timeout = 300（5 分钟）
HikariCP 设 maxLifetime = 1800000（30 分钟，必须 > wait_timeout）
idleTimeout = 600000（10 分钟，介于两者之间，避免雪崩重连）
务必开启泄漏检测：leak-detection-threshold = 60000，日志里一出 Connection leak detection triggered 就能直接定位到哪行代码没 close

排查时优先看 performance_schema.memory_summary_by_thread_by_event_name

别只盯着 innodb_buffer_pool_size 调参。先用系统命令确认是不是真 OOM：pmap -x $(pgrep mysqld) 看 RSS；再进库查：

SELECT thread_id, event_name, SUM_NUMBER_OF_BYTES_ALLOC FROM performance_schema.memory_summary_by_thread_by_event_name ORDER BY SUM_NUMBER_OF_BYTES_ALLOC DESC LIMIT 10;

重点扫 event_name LIKE 'memory/sql/%' 或 'memory/innodb/%' 的行。如果某几个 thread_id 的内存分配量远高于其他线程，再结合 performance_schema.threads 查对应 PROCESSLIST_ID，就能锁定是哪个应用连接在持续吃内存——往往就是那个从不提交事务、也不清理临时表的定时任务。

最常被忽略的一点：mysql_reset_connection() 不是万能的，它不释放由存储过程或触发器内部创建的临时表，也不清 information_schema 查询缓存；这类场景得靠业务逻辑兜底，比如限制单次处理数据量、强制分页、避免在事务里建大临时表。