MySQL执行器不释放内存，真正持有内存的是连接对象；内存仅在连接断开或显式调用mysql_reset_connection()时释放，后者适用于MySQL 5.7+且不重连。
MySQL执行器本身不会主动释放内存
执行器（Executor）只负责调用存储引擎接口、组装结果集、处理 LIMIT 或 ORDER BY 等逻辑，它不管理内存生命周期。真正持有临时内存的是连接对象（thread connection），包括排序缓冲区（sort_buffer_size）、临时表内存（tmp_table_size）、结果集缓存等——这些都绑定在连接上，执行器用完后不会清空，也不会触发释放。
内存实际释放的两个明确时机
MySQL 中与执行相关的内存，只有以下两种情况才会被真正释放：
- 连接断开时：TCP 关闭 + 线程退出，整个连接上下文（含所有 session 级内存）被彻底销毁
- 显式调用
mysql_reset_connection()：仅限 MySQL 5.7+，该函数会重置连接状态，清空当前 session 的所有临时资源（如排序缓存、临时表、用户变量、字符集设置等），但不关闭 TCP 连接、不重新认证权限
注意：mysql_reset_connection() 不是 SQL 语句，而是客户端 API 函数（C/Python/Java 驱动中均有对应封装），不能在 mysql 命令行里直接执行 mysql_reset_connection；误写成 SQL 会报错 ERROR 1064 (42000)。
为什么不能依赖查询结束自动释放
常见误解是“一条 SELECT 执行完，内存就该还回去”。但实际：
- 排序操作（
ORDER BY/GROUP BY）分配的sort_buffer会留在连接里，供下一次查询复用（避免反复 malloc/free 开销） - 大结果集未被客户端完全读取时，服务端仍需缓存剩余数据，直到连接关闭或客户端 fetch 完毕
- 使用了用户变量（如
@var := 1）或 PREPARE/EXECUTE 的语句，其上下文也绑定在连接中
这就是长连接内存持续增长的根本原因：不是执行器忘了释放，而是设计上就让它“留着等下次用”。
生产环境最易忽略的关键点
很多团队加了连接池、设了 maxIdleTime，却没意识到：只要连接没物理断开，哪怕空闲 7 小时 59 分，wait_timeout 到期后 MySQL 是主动 kill 掉这个连接，此时内存才释放——但这个过程不可控，可能刚好卡在大查询中途，导致客户端收到 Lost connection to MySQL server during query。
更稳妥的做法是在业务逻辑中识别高内存操作（比如带 ORDER BY ... LIMIT 10000 的报表查询），执行完立刻调用 mysql_reset_connection()，而不是等连接池回收或超时。
