Navicat 数据同步内存不足无法通过调整 JVM 参数解决，因其为 C++ 应用而非 Java 应用；有效方法是控制每批记录数（5000～10000）、关闭冗余功能、避免全量加载，并在大数据量时改用 mysqldump + 命令行导入。
navicat 数据同步时内存不足，不是调 jvm 参数能解决的——它压根不跑在 jvm 上；真正有效的是控制数据加载节奏、砍掉冗余缓存、避开全量拉取陷阱。
为什么 -Xmx 调整完全无效
Navicat 16 及之后版本是 C++ 桌面应用，进程名是 navicat.exe（Windows）或 Navicat Premium（macOS），没有 -Xmx 启动参数，也不存在 navicat.vmoptions 文件。所有网上教改 JVM 配置的方案，都是把 Navicat 和 DBeaver 等 Java 工具搞混了。
每批记录数设多少才不爆内存
这个值不是越大越好，也不是越小越稳，而是一个需要匹配硬件和字段特征的临界点：
- 设为
5000～10000是实测最平衡区间：低于5000会导致事务太碎、网络往返陡增、总耗时翻倍；高于20000极易触发本地 OOM，尤其当表含TEXT或BLOB字段时 - 注意：
每批记录数控制的是 INSERT 分段提交粒度，不是分页查询——每一批仍会把整批结果集（含大字段）完整载入内存，处理完才释放 - 若任务管理器中
navicat.exe的私有工作集持续超过1.2 GB，说明批次已超载，必须下调
哪些选项一开就吃光内存
这些功能看着方便，但全是内存黑洞，同步前务必关闭：
- 取消勾选「比较数据」和「同步时间戳」：它们会额外加载字段进内存逐行比对，且无法流式处理
- 禁用「自动保存查询」历史、关掉所有未清理的大结果集标签页：这些会持续持有内存引用，仅关闭 tab 不释放
- 避免使用「直接表/视图复制」模式：它会在内存里构建完整映射结构、校验字段兼容性、缓存源/目标元信息，开销远超纯数据传输
- 绝不用
SELECT *：哪怕只同步 10 万行，带TEXT字段就可能占掉 2GB+ 内存；显式写SELECT id, name, created_at FROM t_user
真能绕过内存瓶颈的替代方案
当表行数超千万、单表体积超 5GB，Navicat 就不再是工具，而是瓶颈本身。这时必须换路径：
- 先导出为 SQL 文件：在「数据传输」向导中勾选「导出为 SQL 文件」+「仅 INSERT 语句」+「禁用外键检查」
- 用命令行导入：
mysql -u root -p database_name < dump.sql；它不走 Navicat GUI 内存池，也不缓存执行计划 - 加关键参数防错：
mysqldump --single-transaction --skip-extended-insert可避免锁表和max_allowed_packet错误，而 Navicat 封装层把这些开关全藏掉了
最常被忽略的一点：你以为卡在“同步中”，其实早在你点“开始”前，Navicat 就已把源表全量读进内存做预处理了。只要表结构或数据量超出本地物理内存余量，卡死就是确定性结果，调任何超时参数都没用。
