Navicat 16不基于JVM运行，-Xms/-Xmx参数无效；应通过限制每批记录数（5000～10000）、启用压缩协议、断开重连或复制重建连接来解决内存溢出。
navicat 16 本身不基于 jvm 运行，调整 -xms/-xmx 参数对它完全无效。 这是绝大多数人踩的第一个坑——误把 java 应用的调优思路套到 navicat 上。navicat 是用 c++ 开发的桌面客户端，它的内存行为由操作系统直接管理，没有 jvm 层可调。
为什么改 JVM 参数没用
Navicat 16 的进程在任务管理器里显示为 navicat.exe（Windows）或 Navicat Premium（macOS），不是 java 进程。你在系统里找不到它的 -Xmx 启动参数，也不存在 navicat.ini 或 vmoptions 文件供你修改。所有网上教“编辑 navicat.vmoptions”的方案，基本都混淆了 Navicat 和某些 Java 写的数据库工具（比如 DBeaver）。
真正起作用的三个实操点
解决千万级同步时的内存溢出，核心是控制 Navicat 的数据加载节奏和连接状态：
- 在「数据传输」向导中，务必取消勾选「同步结构」和「同步索引」以外的所有选项，尤其是「同步触发器」「同步存储过程」——它们会额外加载元数据并触发多次查询，极易卡死
- 使用「高级」→「每批记录数」，设为
5000～10000；低于 5000 会导致事务太碎、耗时翻倍；高于 20000 容易触发内存峰值 - 同步前，右键目标连接 →「编辑连接」→「高级」页签 → 勾选「压缩协议」（MySQL/PostgreSQL 支持）；这能减少网络传输体积，间接降低内存压力
同步中途报 “Commands out of sync” 怎么办
这不是 SQL 错误，而是 Navicat 的连接上下文已损坏，典型表现是：刚改过一条记录，再打开同一张表就崩。此时不要重启软件，直接执行：
- 关闭所有打开的查询窗口和表标签页
- 右键该连接 →「断开连接」
- 再右键 →「连接」重新建立会话
- 如果仍失败，按知识库老办法：右键连接 →「复制连接」→ 删除原连接 → 把新连接重命名为原名 —— 这会清空内部缓存状态，比重启更干净
千万级同步的本质不是“快”，而是“稳”。Navicat 不是 ETL 工具，它没有流式处理能力；一旦看到内存占用持续超过 1.2 GB（任务管理器中看 navicat.exe 的私有工作集），说明批次太大或字段含大文本/BLOB。这时候宁可多点几次「下一步」，也不要贪图单次吞下几十万行。
