Navicat 不支持读写分离的自动识别与请求路由，同步必须手动指定主库为源、可写从库为目标；定时同步需用系统任务调度命令行工具，禁用GUI计划；同步模式推荐仅启用Insert records，比对优先用主键匹配；字符集、SQL mode、GTID等连接参数须严格一致。
Navicat 本身不支持读写分离架构的“自动识别主从”同步
navicat 的 data synchronization 和 structure synchronization 功能，全部基于你手动指定的两个连接——它不会感知你数据库是否配置了主从、是否有读写分离代理（如 proxysql、maxscale）、更不会自动把写请求发到主库、读请求发到从库。所谓“读写分离下的同步”，本质是你自己选对源和目标：源必须是主库（或权威数据源），目标是你想更新的从库/只读实例。
常见误操作是：把一个读写分离集群里的两个“同名但角色不同”的连接（比如 prod_rw 和 prod_ro）直接拿来同步，结果发现目标 prod_ro 因为只读权限报错 ERROR 1290 (HY000): The MySQL server is running with the --read-only option。
- 务必确认目标库连接已关闭
read_only=ON（或用具备 SUPER 权限的账号临时关闭） - 源库连接必须能稳定执行
SELECT，且表有主键或唯一索引（否则Update records和Delete records会失效） - 如果目标是中间件后端的多个只读节点，Navicat 只能同步到其中一个；批量更新多个从库需配合脚本 +
mysqldump+mysql或专用工具如pt-table-sync
定时同步必须绕过 Navicat GUI，走系统级调度 + 命令行
Navicat 的「计划」→「新建批处理作业」功能仅在客户端前台运行时有效，锁屏、远程桌面断开、用户登出后立即停止——这在生产环境等于不可用。真正可行的路径只有一条：用系统任务调度器调用 Navicat 命令行工具。
- Windows 下用
navigator.exe -sync "C:\path\to\job.nsx"，配合任务计划程序勾选「不管用户是否登录都要运行」+「使用最高权限运行」 - macOS/Linux 下 Navicat 16+ 自带的
navicatCLI 不支持.nsx同步作业，只能退而求其次：mysqldump --single-transaction --skip-triggers source_db table_name | mysql target_db配合crontab - 所有命令行调用前，必须在 GUI 中先保存一次完整同步配置为
.nsx文件，并取消勾选Save password，改用明文密码填入连接属性（仅限内网可信环境）
同步模式选错会导致从库数据被静默覆盖
在读写分离场景下，目标从库可能已有少量人工干预（如修复脏数据、补录测试记录）。若同步时错误启用 Update records + Delete records，Navicat 会按主库状态强行拉齐，把那些“合理存在但非主库来源”的数据删掉或覆盖。
- 推荐组合：
Insert records开启 +Update records关闭 +Delete records关闭 —— 实现单向追加，规避冲突 - 比对模式优先选
Only primary key matching，避免全表扫描主键外字段（从库负载敏感） - 绝对不要用
Timestamp field模式，除非主从时间严格 NTP 同步且业务层保证updated_at每次必更新
字符集、SQL mode、GTID 兼容性问题最常导致“成功却无变化”
日志显示 Synchronization completed successfully，但目标从库数据没更新、中文变问号、或某张表完全跳过——这类静默失败，90% 出现在连接参数层面，而非同步逻辑本身。
- 两个连接的「高级」设置中，
Character set必须一致（如都设为utf8mb4），且Collation匹配（如utf8mb4_0900_ai_ci） - 目标库连接需显式设置
sql_mode=''或与源库一致，否则INSERT IGNORE可能被拒绝，中断同步流程 - 若开启 GTID，确保源库
gtid_mode=ON且目标库未处于super_read_only=ON状态；否则navigator.exe会卡在连接阶段无提示
