navicat不支持原生多源同步，因其数据同步模块基于一对一连接模型，仅支持单源单目标的逐表比对与dml生成，无法实现多分片聚合；实际需拆分为多个独立单向任务，并确保主键全局唯一、禁用删除、手动协调顺序与去重。
navicat 本身不支持原生的“多源同步到单目标”聚合式同步——它一次只能配置一个 source 和一个 target。所谓“把多个分片数据同步到总库”，必须拆解为多个独立的单向同步任务，再辅以人工或脚本协调。直接在 navicat 界面里选多个源数据库是不可能的。
为什么 Navicat 没有真正的多源同步功能
Navicat 的 Data Synchronization 模块底层是逐表比对 + 生成 DML（INSERT/UPDATE/DELETE）语句执行，所有逻辑都基于「一对一」连接模型。它没有抽象出「聚合视图」或「联邦查询」能力，也不支持在同步前对多个源做 UNION ALL 或去重合并。如果你看到某些教程声称“一键同步多个分片”，基本是混淆了 Data Synchronization 和 Data Transfer，或是用外部脚本包装调用。
实际可行的分片聚合方案：串行多任务 + 手动去重控制
要让多个 MySQL 分片（如 shard_01、shard_02、shard_03）的数据最终落到统一的 central_db.user 表中，你得这么做：
- 每个分片单独建一个同步任务：
shard_01 → central_db、shard_02 → central_db、shard_03 → central_db - 所有任务的目标表必须是同一个
central_db.user，且结构完全一致（字段名、类型、主键定义） - 在每个任务的
Options页中：取消勾选 “Delete records”，只保留Insert records和Update records - 关键：确保所有分片表的主键（或唯一键）设计能全局唯一，比如用
shard_id + auto_increment复合，或 UUID；否则INSERT ON DUPLICATE KEY UPDATE会误覆盖 - 执行顺序建议按业务时间戳或分片权重排序，避免后同步的分片把先同步的更新给冲掉
容易被忽略的三个硬性约束
即使配置正确，以下三点仍会导致同步失败或数据错乱：
-
central_db表必须提前建好，且不能有外键约束指向其他本地表（否则分片同步时可能因缺失关联记录报错） - Navicat 同步时不会自动处理跨分片的逻辑删除标记（如
is_deleted = 1），你需要在源分片 SQL 层过滤掉已删除数据，或在目标端用定时任务清理 - 如果某个分片的某条记录在同步中途被修改，Navicat 不会加锁或做 MVCC 版本校验，结果取决于该次
Compare & Preview快照时刻的状态——也就是说，它不是实时、强一致的同步
真正需要准实时多源聚合的场景，Navicat 只适合作为初始化或低频补漏工具；长期运行请考虑 Flink CDC、Debezium + Kafka + 自定义 sink，或者数据库层的联邦引擎（如 TiDB 的 SHARD_ROW_ID_BITS + REPLACE INTO）。Navicat 的价值在于“看得见、可调试、能回滚”，而不是替代分布式同步基础设施。
