根本原因是长连接不释放线程级内存；MySQL每个连接对应一个线程，其预分配的thread_stack、sort_buffer_size等内存绑定在连接生命周期内，不会随语句执行结束而释放。
长连接不释放线程级内存是根本原因
MySQL每个连接对应一个线程，线程初始化时会预分配 thread_stack、sort_buffer_size、join_buffer_size、tmp_table_size 等内存区域。这些内存**不会在单条语句执行完后立即归还**，而是绑定在连接生命周期内——只要连接没断，这部分内存就一直被线程持有。
典型表现是：执行完一个大 ORDER BY 或带 GROUP BY 的查询后，mysqld 进程的 RSS 内存没回落；再查几次 SHOW PROCESSLIST，发现大量 Sleep 连接的 Time 值持续增长，但内存照涨不误。
- 临时表（
CREATE TEMPORARY TABLE）即使连接空闲也驻留内存+磁盘 - 用户变量（如
@data := LOAD_FILE('/big.bin')）不会自动清空 - 预处理语句（
PREPARE stmt FROM ...）不DEALLOCATE PREPARE就一直占着几百字节
wait_timeout 对心跳连接完全无效
wait_timeout 只杀“真睡觉”的连接——即连续 wait_timeout 秒内没有任何命令交互。但现代应用普遍用连接池 + 心跳保活（比如每 30 秒发一次 SELECT 1），这会让连接永远卡在 Sleep 状态却永不超时。
结果就是：数据库侧的超时机制形同虚设，而应用层又没主动轮换连接，内存就这么一小时一小时地堆上去。
-
wait_timeout默认 28800 秒（8 小时），很多连接池配置为 0 或极大值，等于关掉了这道闸 - 即使设成 300 秒，只要心跳间隔 ≤ 299 秒，连接就永远不会触发断开
- 服务端 KILL 连接时，客户端通常收不到通知，下次复用直接报
Lost connection to MySQL server during query
mysql_reset_connection() 是最轻量的重置手段
MySQL 5.7.3+ 提供 mysql_reset_connection()，它不重建 TCP 连接、不重走权限验证流程，只把当前连接恢复到刚创建时的状态：清空用户变量、释放临时表、重置会话级缓冲区（sort_buffer_size 等回归初始值）。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
相比断连重连，它开销极小；相比坐等 wait_timeout，它可控可编程。
- Java 的
mysql-connector-java 8.0.14+支持调用connection.resetConnection() - Python 的
PyMySQL和mysql-connector-python需手动发送COM_RESET_CONNECTION包（或升级到支持该命令的版本） - Node.js 的
mysql2暂未封装该能力，需通过connection.changeUser({})间接模拟（效果接近但非等价）
连接池必须配 maxLifetime + idleTimeout 错峰
靠数据库侧被动清理不可靠，真正有效的策略是让连接池自己强制轮换连接。关键不是“能不能用”，而是“最多用多久”和“最多干多少事”。
例如 HikariCP 推荐配置：maxLifetime=1800000（30 分钟）、idleTimeout=600000（10 分钟）、leakDetectionThreshold=60000（1 分钟泄漏检测）。三者错开，避免所有连接在同一时刻集中重建造成雪崩。
- 不要依赖
testOnBorrow，它只验连通性，不清理会话状态 - 必须配
validationQuery=SELECT 1，否则失效连接可能被复用并携带脏状态 - 事务中禁止长期 hold 连接——
START TRANSACTION; SLEEP(60); COMMIT;会让整个线程内存锁死一分钟
真实线上问题往往不是单一因素：连接池没设 maxLifetime，应用又没调 mysql_reset_connection()，同时业务代码里还藏着未 DROP TEMPORARY TABLE 的逻辑——三者叠加，内存几个小时内就能从 2G 涨到 12G。盯住 Threads_connected、Created_tmp_tables、Handler_read_rnd_next 这几个指标，比单纯看 free -h 的 used 有用得多。
