直接复制.nsx文件会失败，因其仅记录作业逻辑而不含连接凭据、依赖本地已命名连接、密码加密绑定旧硬件、SSH私钥路径未保存。
navicat 12 的自动化任务（.nsx 文件）不能直接复制粘贴到新服务器上运行，必须配合连接配置重置、密码处理和命令行调用路径修正才能生效。
为什么直接复制 .nsx 文件会失败
Navicat 12 的 .nsx 文件本质是作业描述，不包含实际连接凭据或环境上下文。它只记录了“用哪个连接、同步哪张表、映射哪些字段”，但所有连接对象（SourceServer、TargetServer）都指向本地 Navicat 配置中已命名的连接名——这些连接名在新机器上并不存在，除非你已导入对应的 connections.ncx。
常见错误现象包括：Failed to load connection、Connection refused、任务静默退出无日志。
关键原因有三：
-
.nsx中引用的连接名在新 Navicat 实例中未定义 - 连接配置里若勾选了
Save password，Navicat 12 会加密绑定旧主机硬件信息，换机后密码不可解密 - 若用了 SSH 隧道，
.nsx不保存私钥路径，而 Navicat 12 在命令行模式下无法弹出密码输入框，导致隧道建立失败
迁移前必须完成的三步准备
跳过任意一步，navigator.exe -sync 命令大概率报错退出。
- 在旧机器上导出全部连接：
文件 → 导出连接 → 保存为 connections.ncx（注意不是手动拷Profiles目录） - 在新机器安装同版本 Navicat 12（v12.1.x 与 v12.0.x 之间可能不兼容
.nsx解析），然后执行文件 → 导入连接，选中刚导出的connections.ncx - 逐个编辑导入后的连接：取消勾选
Save password，手动填入明文密码（仅限内网可信环境）；若走 SSH，确认私钥路径是绝对路径（如C:\Users\Me\.ssh\id_rsa），且文件确实存在
如何验证并运行迁移后的 .nsx 任务
Navicat 12 不支持 GUI 内直接“另存为已配置的 .nsx”再导出，它的 .nsx 只能通过「自动运行」面板生成并保存。因此迁移时要确保原始任务是在旧机器上点过「另存为作业」的。
验证步骤如下：
- 打开 CMD，执行：
"C:\Program Files\PremiumSoft\Navicat 12\navigator.exe" -sync "D:\jobs\my_sync.nsx"（路径含空格必须加英文双引号） - 若提示
Sync job executed successfully，说明基础通路已通；若报Invalid server name，说明.nsx里写的连接名和新 Navicat 中的实际连接名不一致（比如旧的是prod_192.168.1.10，新导入后变成了prod_192.168.1.10 (1)） - 修改
.nsx文件本身（它是 XML 格式）：用文本编辑器打开，搜索<SourceServer>和<TargetServer>标签，把里面的值改成新 Navicat 中显示的确切连接名 - Windows 任务计划程序中新建任务时，务必勾选「不管用户是否登录都要运行」+「使用最高权限运行」+「运行时请勿显示界面」，否则
navigator.exe会卡在 GUI 初始化阶段
容易被忽略的底层依赖
即使 .nsx 路径、连接名、密码全对，任务仍可能在执行时失败——问题往往不在 Navicat，而在 MySQL 服务端配置。
- 目标 MySQL 的
bind-address必须设为0.0.0.0（不能是127.0.0.1），否则 Navicat 从远程发起的连接会被拒绝 - 同步账号的
host字段必须是'sync_user'@'%'或具体 IP，不能只留'localhost'；可通过SELECT User, Host FROM mysql.user;确认 - 如果源库启用了
secure_file_priv，且迁移涉及LOAD DATA INFILE操作（某些数据传输模式会触发），需确保该路径在目标库也开放且可写
真正落地时，最耗时间的往往不是配置 Navicat，而是反复核对 MySQL 的网络策略与账号权限细节。
