Navicat 15 不支持内置跳板机连接，必须先通过SSH端口转发等网络层手段打通链路，再配置直连参数实现结构或数据同步。
navicat 15 本身不支持通过跳板机（中转代理）自动建立数据库连接，也不能在「结构同步」或「数据同步」流程中内置 icmp / ssh / socks 等穿透逻辑。如果你的两台云主机中有一台无法被 navicat 直连（比如它在严格内网、无公网 ip、防火墙只放行 icmp），那必须先解决连接可达性问题，再谈同步。
Navicat 同步前必须能直连源和目标数据库
Navicat 的 结构同步 和 数据同步 功能都依赖 JDBC/ODBC 或原生协议（如 MySQL 的 TCP 3306）建立稳定、双向、低延迟的连接。它不会帮你做端口映射、隧道转发或协议转换。
- 如果目标数据库监听在
192.168.1.100:3306，而你的本地机器 ping 不通这个地址，Navicat就会报错：Connection refused或Can't connect to MySQL server - 即使你用
Pingtunnel把 ICMP 流量转成了 TCP，Navicat 也无法识别或使用该隧道——它不读取系统代理设置，也不支持自定义传输层封装
所以第一步永远是：让 Navicat 能像访问本地库一样访问远端库。
跳板机不是 Navicat 的功能，而是网络层的事
你得在操作系统或终端层面打通链路，常见可靠做法：
-
使用 SSH 本地端口转发（推荐，简单、加密、无需额外工具）
ssh -L 3307:192.168.1.100:3306 user@jump-server-ip
然后在 Navicat 中把目标数据库主机填成127.0.0.1，端口填3307 使用
autossh保活，防止断连若跳板机只开放 ICMP（如某些安全加固环境），则必须先用
Pingtunnel在跳板机上起一个监听服务，再在本地起 client 解包还原 TCP，最后让 Navicat 连本地映射端口 —— 但这要求你手动部署并维护两段 tunnel，且Pingtunnel的稳定性、吞吐和并发能力远不如 SSH
注意：
-
Navicat不会提示你“检测到网络不可达，是否启用隧道”——它只报错 - 所有 tunnel 配置必须在 Navicat 启动之前就绪；Navicat 不会重试或自动重连中断的隧道
结构同步时最易忽略的兼容性陷阱
即使连上了，同步仍可能失败或静默出错：
- 字符集不一致：源库用
utf8mb4_unicode_ci，目标库是utf8_general_ci→ 表创建会报Specified key was too long - MySQL 版本跨大版本（如 5.7 → 8.0）：
CREATE TABLE中的DEFAULT CURRENT_TIMESTAMP语法在 5.6 不被支持 - 目标库开启了
sql_mode=STRICT_TRANS_TABLES，而源库没开 → 某些字段默认值插入失败 - Navicat 默认勾选「删除目标中不存在的对象」，如果误选了「要删除的对象」→ 整张表被
DROP
建议操作：
- 同步前用
mysqldump --no-data导出两边 DDL 对比 - 在「结构同步」的「比对」结果页，手动取消勾选「要删除的对象」（除非你明确要清空目标）
- 首次同步优先选「仅创建 & 修改」，跑通后再考虑增量清理
数据同步中「删除记录」选项的实际影响
数据同步 功能里的「删除记录」勾选项，控制的是：当某条记录在源库已不存在、但在目标库还存在时，是否执行 DELETE。
- 勾选 → 目标库变成源库的完全镜像（含删减）
- 不勾选 → 只增、只改，不删（适合日志表、审计表等不能丢历史的场景）
但要注意：
- 它依赖主键或唯一键匹配；若表没主键，Navicat 会按全字段比对，性能极差，且容易误判
- 若源库和目标库时间不同步，用
updated_at做增量条件时可能漏数据 - 同步中途断掉，Navicat 不支持断点续传；再次运行会重新全量比对（耗时长，压力大）
真正需要高可靠双向同步的场景，Navicat 不是合适工具——它本质是 DBA 辅助工具，不是生产级同步服务。
跳板机配置和 Navicat 同步是两层事：前者解决“能不能连”，后者解决“连上了怎么同步”。很多人卡在第一层却以为是 Navicat 设置不对。只要连接不通，后面所有按钮都是灰色的，所有教程都白看。
