Navicat数据传输中设置每批记录数需进入“工具→数据传输→高级→每批记录数”，推荐值5000～10000；该参数影响内存占用与提交频率，不控制事务边界，且仅对INSERT有效。
数据传输向导里怎么设每批记录数
navicat 的「每批记录数」只在「数据传输」功能中生效，不是在「同步」或「结构同步」里——很多人点错入口，根本找不到这个选项。
操作路径：工具 → 数据传输 → 选好源和目标 → 点击右下角「高级」→ 找到「每批记录数」输入框。默认值通常是 1000，但对千万级表来说太小（事务太碎）或太大（内存爆掉）都不合适。
- 5000～10000 是实测较稳的区间；低于 5000 会让 COMMIT 频次过高，耗时翻倍；高于 20000 容易触发 navicat.exe 私有工作集突破 1.2 GB，任务管理器里能直接看到内存飙升
- 含
BLOB、TEXT或长字符串字段时，建议先压到 2000 试跑；若某张表字段全是VARCHAR(20)且无索引膨胀，可试探性提到 15000 - 这个值不控制事务边界（Navicat 不暴露事务大小参数），但会影响单次加载进内存的行数——本质是调节内存压力，不是调原子性
为什么改 JVM 参数完全没用
Navicat 16 是 C++ 写的桌面程序，进程名是 navicat.exe（Windows）或 Navicat Premium（macOS），不是 Java 进程。所有教你怎么改 -Xms、-Xmx 或编辑 navicat.vmoptions 的方案，都混淆了它和 DBeaver 等 Java 工具。
你在任务管理器里看不到 JVM 相关内存指标，系统里也搜不到任何 vmoptions 文件。强行修改只会白忙活，还可能破坏其他 Java 应用的配置。
- 真正影响内存的是「每批记录数」+ 字段类型 + 是否启用压缩协议
- 如果同步中途 navicat.exe 内存持续 > 1.2 GB，第一反应不是调虚拟机参数，而是立刻把批次降到 5000 并勾选「压缩协议」
- 某些老教程截图里的「JVM 设置」标签页，实际属于 Navicat 的旧版本分支（如 Navicat for Oracle 早期版），不适用于当前主流的 Navicat Premium 16/17
遇到 Commands out of sync 别重启软件
这不是 SQL 错误，是 Navicat 内部连接状态损坏的典型信号：刚更新一行，再打开同一张表就崩，或者同步卡在某个表不动。重启软件治标不治本，因为缓存状态没清干净。
- 先关闭所有打开的查询窗口和表标签页
- 右键对应连接 →「断开连接」→ 再右键 →「连接」重建会话
- 如果仍失败，右键连接 →「复制连接」→ 删除原连接 → 把新连接重命名为原名；这比重启更彻底，能清掉内部游标和未释放的 result set
这种问题常在大批量同步后出现，尤其当「每批记录数」设得过大，或源库 wait_timeout 过短导致连接被服务端静默关闭时。
源库超时设置必须配合 Navicat 自身保活开关
只调 MySQL 的 wait_timeout 和 interactive_timeout 不够——Navicat 自己也会主动断连。它有个隐藏逻辑：即使服务端没杀连接，客户端空闲久了也会发 COM_QUIT。
- 源库侧：两个 timeout 值建议统一设为
86400（24 小时），并确认已写入my.cnf的[mysqld]段落且 MySQL 已重启 - Navicat 侧：编辑连接 →「高级」页签 → 取消勾选「自动断开空闲连接」（部分版本叫
Disconnect when idle） - 同时确保「保持连接活跃」已勾选，ping 间隔设为
60秒（必须小于服务端 timeout 的 1/10）
这两个地方漏一个，同步到一半就断，而且 Navicat 不支持断点续传——中断后全部重来，没有“已同步到第 X 行”的记录。
