自动任务比手动操作更容易oom，因其后台线程持续加载结果、缓存ast、维持连接快照且无法被用户中断；日志和执行结果缓存占内存70%，禁用这两项最有效。
为什么自动任务比手动操作更容易 OOM
Navicat 自动任务在后台线程中持续加载结果、缓存 AST 语法树、维持连接元数据快照，且不会像 GUI 操作那样被用户中断或分页释放。即使你设了“每批 1000 行”，运行 SQL 文件 类任务仍会先全量读入内存再切片——这是解析阶段，不是执行阶段。日志级别设为“详细”时，每条 INSERT 的返回状态、影响行数、错误堆栈都会被序列化缓存，极易撑爆内存。
关掉「记录详细日志」和「保存执行结果」
这是见效最快、无需改脚本的实操项。自动任务的内存压力约 70% 来自这两项冗余缓存。
- 打开任务编辑页 → 切换到「高级」选项卡 → 取消勾选
记录详细日志和保存执行结果 - 若使用「数据传输」类任务，在「选项」里把
Fetch Size显式设为500（默认为0表示全取） - 禁用
启用查询分析器——它后台持续收集执行计划，是长周期任务的内存黑洞
别信 -Xmx 参数，Navicat 16 不走 JVM
Navicat 16 是 C++ 写的桌面客户端，进程名是 navicat.exe 或 Navicat Premium，不是 Java 进程。所有网上教改 navicat.vmoptions 或加 -Xmx4096m 的方案都无效——它根本没有 JVM 层可调。
真正起作用的是控制数据加载节奏：
- 在「数据传输」向导中，取消勾选
同步触发器、同步存储过程等非必要元数据同步项 - 「高级」→
每批记录数设为5000～10000；低于5000事务太碎，高于20000容易触发内存峰值 - 右键连接 →「编辑连接」→「高级」页签 → 勾选
压缩协议（MySQL/PostgreSQL 支持），减少网络传输体积
真要稳，就别用 Navicat 自动任务跑大 SQL
当数据量超 500MB 或 1000 万行，Navicat 的 GUI 内存模型已到极限。它没有流式处理能力，本质不是 ETL 工具。
- 改用系统级命令行：
mysql --force -u root -p'pass' -D database_name ，绕过全部中间层 - SQL 文件含
USE db_name;？删掉，改用-D显式指定库，防止跨库解析异常 - 大文件务必提前拆分：
split -l 10000 full.sql part_（Linux/macOS），或用 PowerShell 分批导出 - 自动调度用
cron或 Windows 任务计划程序，而不是 Navicat 自带的任务调度器——后者在休眠或 GUI 挂起时容易卡死连接上下文，内存无法回收
