为什么MySQL长连接会导致内存占用过高_通过定期重连或执行mysql_clear

mysql_reset_connection()比单纯重连更可靠，因其在不重建连接的前提下重置会话级资源（如排序缓冲、临时表、用户变量等），避免tcp握手与认证开销，但事务中调用会隐式回滚。

为什么mysql长连接会导致内存占用过高_通过定期重连或执行mysql_clear_session

MySQL长连接本身不分配“额外”内存，但每个连接绑定的线程栈、排序缓冲区、临时表内存等资源是独占且不随语句结束自动释放的——只要连接活着，这些内存就一直挂着。定期重连或调用 mysql_reset_connection() 是目前最直接有效的缓解手段，但必须配合正确时机和清理逻辑，否则只是把问题延迟。

为什么 `mysql_reset_connection()` 比单纯重连更可靠

这个函数在 MySQL 5.7.3+ 和 Connector/J 8.0.14+ 中可用，它不只是清空会话变量，还会重置：sort_buffer_size、join_buffer_size、用户变量（@var）、临时表（CREATE TEMPORARY TABLE）、预处理语句（PREPARE）缓存、字符集设置等。而简单断开再重连，虽然也能释放全部资源，但会带来 TCP 握手开销、认证延迟、连接池抖动等问题。

常见误用点：

在事务中调用 mysql_reset_connection() 会隐式执行 ROLLBACK，导致数据丢失
旧版驱动（如 mysql-connector-python NotSupportedError
Node.js 的 mysql2 需显式启用 enableKeepAlive: true 才能复用连接并安全调用

定期重连不是“定时 kill”，而是连接池主动轮换

靠 wait_timeout 被服务端踢掉连接不可控：客户端收不到通知，下次使用直接报 Lost connection to MySQL server during query；而且心跳（如 SELECT 1）会让超时完全失效。

Session Monitor

实时 OpenClaw 会话监控器，追踪 JSONL 记录并以持久后台进程向 Telegram 推送格式化更新。适用于在被询问时

下载

真正可控的做法是让连接池自己决定连接“活多久”：

HikariCP：设 maxLifetime=1800000（30 分钟），idleTimeout=600000（10 分钟），两者错开避免雪崩
Druid：配 maxEvictableIdleTimeMillis=600000 + minEvictableIdleTimeMillis=300000，并开启 removeAbandonedOnMaintenance=true
Python（SQLAlchemy + PyMySQL）：在 creator 函数里每次获取连接后检查 connection.connection_id，累计执行语句数超 500 条就主动 close() 并新建

哪些场景下 `mysql_reset_connection()` 会失效

它解决不了底层资源泄漏，比如：

未提交的长事务：START TRANSACTION 后卡住，undo log、锁结构、事务内存不会被重置
大结果集未读完：调用后仍持有网络缓冲区和内部游标，直到 fetchall() 或连接关闭
插件或 UDF 分配的内存：如 lib_mysqludf_sys 调用系统 malloc，不在 MySQL 会话管理范围内
InnoDB 缓冲池页：这是全局共享的，跟单个连接无关，mysql_reset_connection() 不影响它

最易被忽略的一点：即使你每 5 分钟重连一次，如果应用层在连接归还池前没显式 SET @var = NULL 或 DROP TEMPORARY TABLE IF EXISTS tmp_x，而驱动又没自动调用 mysql_reset_connection()，那这些资源就会在新连接里继续累积——相当于把泄漏从“一个连接”扩散到“所有连接”。