Navicat的「数据传输」功能本身不支持跨服务器自动同步，它仅是本地GUI工具，无服务端调度能力；所谓“自动”需依赖命令行调用navigator.exe执行.ns x作业，并配合系统级定时器（如Windows任务计划程序），且必须满足远程访问、SSH隧道配置、字符集一致等硬性前提。
Navicat 的「数据传输」功能本身不支持跨服务器自动同步——它只是个本地 GUI 工具，没有服务端调度能力，也不能脱离用户登录态和前台运行环境独立执行。所谓“跨服务器同步”，实际是靠你在本机同时连上源库和目标库，手动点击「开始」完成的一次性搬运；若想“自动”，必须绕开 Navicat 自带的「自动运行」界面，改用命令行调用 + 系统级定时器组合实现。
为什么 navigator.exe -sync 能跑通，但任务计划里总失败
根本原因在于权限、上下文和路径三重隔离：
-
navigator.exe启动时默认继承当前用户的桌面会话环境；而「任务计划程序」中若未勾选「不管用户是否登录都要运行」+「使用最高权限运行」，它会在无桌面会话的 Session 0 下静默启动，导致 GUI 组件加载失败、SSH 隧道无法建立、密码读取异常 - 所有连接配置（尤其是含 SSH 隧道的）必须在 .nsx 文件中保存为明文密码（
Save password必须关闭），否则navigator.exe无法解密凭据 - .nsx 文件路径、密钥文件路径（如
C:\Users\Me\.ssh\id_rsa）必须是绝对路径，不能用~或相对路径；navigator.exe不解析 shell 环境变量
MySQL 跨服同步前必须验证的三个底层连接条件
即使 Navicat GUI 能连上，navigator.exe 命令行也可能失败，因为它的网络栈更严格：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 源/目标 MySQL 的
bind-address不能是127.0.0.1，得设为0.0.0.0或具体 IP；否则navigator.exe从本机发起的连接会被拒绝 - 数据库用户 host 必须显式授权远程访问，例如
'sync_user'@'%'或'sync_user'@'192.168.1.100'；仅'sync_user'@'localhost'在跨服场景下完全无效 - 若走 SSH 隧道，Navicat 连接配置里的「密钥文件路径」必须填 Windows 绝对路径（如
C:\navicat_keys\prod_rsa），且该文件 NTFS 权限需允许 SYSTEM 和任务计划所用账户读取
字符集与表结构不一致时的数据传输行为
Navicat 数据传输不会自动修正字符集冲突或字段类型不兼容，而是直接报错中断：
- 若源表用
utf8mb4、目标库默认字符集是utf8，传输会卡在建表阶段，报错Unknown character set: 'utf8mb4' - 若源字段是
JSON类型（MySQL 5.7+），目标 MySQL 5.6 不支持，传输直接失败，不降级兼容 - 目标库表不存在时，Navicat 只能按源表 DDL 创建新表；但若目标已有同名表且结构不同（比如少一个索引），它不会 ALTER，而是跳过建表、只传数据——此时数据可能因缺失约束而写入失败
真正可靠的跨服同步，从来不是靠 Navicat 点几下就完事；它只适合一次性迁移或内网低频同步。高频、生产级的自动同步，必须用 mysqldump + mysql 管道、或 pt-table-sync 这类专为一致性设计的工具——它们能处理断点续传、校验和、行级差异，而 Navicat 的同步逻辑是全量覆盖式，容错粒度太粗。
