Navicat“自动运行”非真定时，仅客户端前台时有效；稳定方案为系统级调度调用其命令行工具或换用服务化同步工具。
Navicat 的「自动运行」功能根本不能真正定时同步
navicat 本身没有后台服务或系统级定时器，所谓“自动运行”只是在 navicat 客户端打开且处于前台时，按设定间隔尝试执行任务——关掉软件、切到其他窗口、锁屏后基本就停摆。这不是 bug，是设计限制。
真正能稳定定时的方案只有两条路：用操作系统级调度（Windows 任务计划程序 / macOS cron / Linux systemd timer）驱动 Navicat 命令行工具；或者换用支持服务化部署的同步工具（如 DataGrip + 自定义脚本、pt-table-sync、或云厂商的数据迁移服务）。
实操建议：
- 确认你用的是
Navicat Premium或Navicat for MySQL15+ 版本——只有这些版本附带navicat.exe（Windows）或navicat（macOS/Linux）命令行工具 - 先手动导出一次同步任务为
.ncx文件（右键同步任务 →「导出任务」），这是命令行执行的唯一入口 - Windows 下用任务计划程序调用：
navicat.exe -runjob "C:\path\to\task.ncx"；macOS/Linux 下用：./navicat -runjob "/path/to/task.ncx" - 务必勾选任务属性里的「不管用户是否登录都要运行」和「使用最高权限运行」，否则常见报错：
Failed to load job: Permission denied
同步任务里「比较模式」选错会导致数据被意外覆盖
Navicat 同步默认用「结构 + 数据」双比对，但实际场景中，多数人只需要更新目标库的增量数据（比如测试库每天拉生产库的最新订单表），而不是全量重建。选错模式轻则同步极慢，重则把目标库已有的修改（如人工修正的备注字段）直接回滚。
关键判断点：
- 用「逐行比较」模式时，Navicat 会读取所有行的主键+所有字段值做哈希比对——表越大越卡，10 万行以上就明显延迟，且要求源/目标表必须有主键或唯一索引
- 用「时间戳字段」模式需提前在两张表里加同名
updated_at字段并确保准确更新，否则漏同步；不推荐给没有规范更新逻辑的老系统用 - 最稳的其实是「仅主键匹配」：只比对主键是否存在，存在则跳过，不存在则插入——适合单向追加场景，但无法处理更新和删除
跨环境同步时字符集与 SQL 模式不一致会静默失败
常见现象是：任务显示「成功」，但目标库数据没变，或中文变问号，或 INSERT IGNORE 被转成普通 INSERT 导致主键冲突中断。根源往往不在同步设置，而在连接参数。
必须检查的三项：
- 两个连接的「高级」设置里，
Character set必须一致（比如都设为utf8mb4），不能一个写utf8一个留空 - MySQL 连接的
SQL Mode要对齐，尤其注意STRICT_TRANS_TABLES和NO_ZERO_DATE—— 生产库开了严格模式，测试库没开，就可能让某些默认值插入失败却不报错 - 如果源库是 MySQL 5.7，目标库是 8.0，务必在同步选项里取消勾选「保持 AUTO_INCREMENT 值」，否则可能因 8.0 的自增锁机制导致同步卡死
日志里出现 Connection refused 却能手动连上？查防火墙和连接池
命令行触发同步时突然连不上，但 Navicat GUI 点几下又能通——大概率是操作系统层面的连接数限制或连接池未释放。Navicat 命令行工具不会复用 GUI 的连接，每次都是新进程、新 TCP 连接。
排查优先级：
- Windows 上检查
netsh interface ipv4 show dynamicport tcp，确认临时端口范围足够（默认 49152–65535，高频定时任务可能耗尽） - MySQL 服务端的
max_connections要预留至少 20 个空闲连接给同步任务，别全被应用占满 - 如果用了 SSH 隧道，命令行里必须显式指定
-ssh参数并带上私钥路径，GUI 里存的密码或密钥不会自动继承 - 加个简单重试逻辑：用 shell 脚本包装命令行调用，失败后 sleep 5s 再试一次，避免偶发网络抖动误判
复杂点在于：Navicat 命令行不返回标准错误码，echo %ERRORLEVEL% 或 $? 基本恒为 0，真要判断成败得去解析日志文件里的 Success / Failed 字符串——这点几乎没人提，但线上无人值守时最关键。
