navicat 17无法实现分布式数据库跨节点自动数据同步，因其无cdc、不监听binlog、不维护同步位点，所有同步均为手动触发、离线批量、单向快照比对与搬运。
Navicat 17 无法对分布式数据库做“跨节点自动数据同步”——它没有 CDC、不监听 binlog、不维护位点，所有同步都是手动触发、离线批量、单向搬运。
Navicat 的 Data Synchronization 不是分布式同步工具
很多人看到“同步”二字就默认它能像 ShardingSphere-Proxy 或 Vitess 那样感知分片拓扑、路由写入、协调事务。实际不是：Data Synchronization 只比对两张表的当前快照（SELECT 全量 or 带 WHERE 的子集），生成 INSERT/UPDATE 语句并执行。它完全不知道你有 8 个 MySQL 分片，也不知道哪些数据该去 shard_03 还是 shard_07。
常见错误现象包括：
- 用
Data Synchronization对 shard_01 → shard_02 同步后，再对 shard_02 → shard_03 执行，结果 shard_03 里出现 shard_01 的旧数据覆盖了 shard_02 的新修改 - 没关
Delete records，同步时把目标分片上其他业务写入的合法记录删了 - 跨分片主键冲突：shard_01 和 shard_02 都用
AUTO_INCREMENT，起始值都是 1，同步时直接报Duplicate entry '1' for key 'PRIMARY'
必须手动拆解为单向任务 + 强约束条件
真正在分布式场景下“可控使用”，得放弃“一键同步全部节点”的想法，转为按业务流定义明确的搬运路径。例如：所有上游写入走 shard_01，下游报表库需定期拉取最新状态，则只建 shard_01 → report_db 一条单向链路。
实操要点：
- 每次只选一个源 + 一个目标，不要试图用“一对多”或“环形同步”
- 在
Options中禁用 Delete records，避免误删分片本地产生的中间态数据 - 务必在
Where Condition填时间范围，如updated_at > DATE_SUB(NOW(), INTERVAL 1 HOUR)，否则全表扫描会锁表且拖垮线上查询 - 如果目标库是只读从库，确认其
read_only=OFF，否则INSERT/UPDATE直接被拒绝 - 同步前手动执行
SELECT COUNT(*)校验源/目标行数差异是否在预期范围内，别依赖 Navicat 的“比对完成”提示
跨异构库（如 MySQL ↔ SQL Server）同步要额外防三类坑
Navicat 支持跨库类型传输，但分布式环境下放大了兼容性问题：
-
datetime字段在 SQL Server 中精度为 3.33ms，在 MySQL 中可到微秒，WHERE 条件用>容易漏掉最后几毫秒的数据 - SQL Server 的
IDENTITY和 MySQL 的AUTO_INCREMENT无法对齐，必须提前把主键改为 UUID 或业务编码，否则Data Synchronization会反复失败 - Oracle 的
NUMBER(10,2)映射到 SQL Server 的DECIMAL时若未显式指定精度，Navicat 可能默认用DECIMAL(18,0)，导致小数位丢失 - 字符集不一致（如源库 utf8mb4，目标库 Latin1）会导致中文字段同步成 ?，且 Navicat 不报错，只静默截断
真正棘手的不是操作步骤，而是你得清楚知道哪张表在哪个分片上承担什么角色、谁负责写、谁只读、有没有本地缓存逻辑——Navicat 不帮你记这些，它只管搬数据。一旦业务模型变化（比如新增一个写入口分片），所有已配置的同步任务都得人工重审，漏掉一个就可能引发数据漂移。
