navicat 导出数据时内存持续飙升且不释放，根本原因是其设计为“先构建再写入”，全程在jvm堆中缓存sql语句、表结构、blob/text转义结果及字符集映射等全量中间数据。
Navicat 导出数据时内存持续飙升不释放，根本原因不是它“忘了释放”，而是设计上就**不释放**——导出过程全程在内存中拼接 SQL 语句、缓存表结构、处理 BLOB/TEXT 字段转义、维护字符集映射表，并且所有中间结果都保留在 JVM 堆里直到导出完成。哪怕你只导出一张 100 万行的表，navicat.exe 的工作集也可能冲到 2GB+ 且不回落。
导出时哪些操作会强制全量驻留内存
Navicat 的导出逻辑是“先构建再写入”，不是流式生成。以下行为会让它把整张表或整个库结构提前加载进内存：
-
导出为 SQL 文件时勾选了「导出表数据」+「导出存储过程」+「导出事件」：每个对象都要解析 AST、提取依赖、做语法树校验，全部缓存在堆中 - 表中含
MEDIUMBLOB或LONGTEXT字段：Navicat 默认将其 base64 编码后塞进 INSERT 语句，原始二进制 + 编码后字符串双份内存占用 - 导出路径含中文或空格（如
C:\用户\文档\backup.sql）：参数解析失败导致内部重试机制反复构造临时语句对象，对象引用无法 GC - 启用了「压缩输出」或「添加注释」：每行 INSERT 都要额外生成注释字符串、做 GZIP 缓冲区预分配，且缓冲区大小按预估最大值分配
Fetch Size 设为 0 是最隐蔽的内存陷阱
很多人以为「Fetch Size」只影响查询结果集分页，其实它也控制导出时的读取批次。在「导出向导 → 高级」里，如果 Fetch Size 留空或设为 0，Navicat 会默认启用“全表拉取”模式——即一次性 SELECT * FROM table_name 到本地内存，再逐行转 SQL。这不是性能选项，是内存开关。
- 正确做法：显式设为
500或1000（不要用 0） - 验证是否生效：导出中途打开任务管理器，观察 navicat.exe 的“工作集”内存是否呈阶梯式缓慢上涨（每批加载一次），而不是瞬间飙高后卡住
- 注意：该设置只对「导出向导」有效；「运行 SQL 文件」和「数据传输」任务里的 Fetch Size 是独立配置项
导出完成后内存仍不回落的三个真实原因
即使导出窗口已关闭，navicat.exe 内存可能维持高位数分钟甚至更久。这不是泄漏，而是 JVM 行为叠加 Navicat 的资源复用策略：
- 连接未真正断开：右键连接 →「断开连接」只是关闭逻辑通道，底层 JDBC 连接池中的物理连接仍被缓存 5 分钟（默认），连带其关联的结果集元数据、列类型缓存一并驻留
- 临时文件句柄未释放：导出过程生成的
navicat_*.tmp文件若被 OneDrive / Dropbox / Windows Defender 实时扫描锁定，JVM 无法回收对应 FileChannel 对象 - 编辑器历史残留：如果你在导出前刚执行过复杂查询，
SQL 历史记录中保存的完整结果摘要（含行数、耗时、字段名列表）仍占着堆，尤其当历史数设为 1000（默认）时
真正容易被忽略的是：Navicat 的内存模型是“连接上下文强绑定”的。哪怕你只导出一个表，只要同一连接下还有另一个标签页开着大查询结果集，那个结果集的缓存就不会释放——它和导出任务共享同一堆空间。关掉所有标签页、手动断开连接、再等 30 秒，才是让内存真正回落的最小可靠动作。
