Navicat“自动运行”中添加多个数据同步操作，需在批处理作业中多次点击“添加任务”，分别配置各源库到同一目标表的同步操作，启用“插入记录+更新记录”合并模式，禁用“删除记录”，并确保主键一致、字段映射正确。
“自动运行”任务里怎么加多个数据同步操作
Navicat 的 自动运行 工具本身不支持在一个任务中直接配置“多源合并”逻辑，它一次只跑一个操作（比如一次同步、一次备份）。想实现多源汇聚，得靠组合多个独立的 数据同步 操作，并把它们塞进同一个批处理任务里。
实际做法是：在 自动运行 编辑界面，点击“添加任务”按钮多次，每次添加一个 数据同步 类型的操作。每个操作单独配置源库（如 branch_a）、目标表（如 central_db.user），并确保都启用“合并”模式（即不勾选 删除记录）。
- 必须为每个源库单独建一条同步操作，不能用通配符或批量表选择自动遍历
- 所有同步操作的目标表必须结构一致，否则后续写入会报错（如字段类型不匹配、主键冲突）
- 建议按源库顺序排列任务项，避免并发写入同一张目标表引发锁等待（Navicat 不自动加事务隔离控制）
为什么“合并模式”必须关掉“删除记录”
这是防止误删的核心开关。一旦勾选 删除记录，Navicat 会在同步时执行类似 DELETE FROM target WHERE id NOT IN (SELECT id FROM source) 的逻辑——这会清掉目标表里所有“不在当前源表中”的行。而多源汇聚场景下，你希望的是“追加 + 更新”，不是“以某一个源为准覆盖全量”。
正确配置只勾选 插入记录 和 更新记录，且确保每条同步操作都基于同一组主键/唯一键（如 id 或 user_id）做比对。否则会出现重复插入或更新失效。
- 如果源表没有定义主键或唯一索引，Navicat 会退化为全表扫描比对，性能差且容易漏判更新
- 不同源的数据若共用同一主键空间（例如都用自增
id），必须提前规划好 ID 分段或改用业务主键（如tenant_id + user_no） - 时间戳字段（如
updated_at）不能作为同步依据——Navicat 的“更新记录”逻辑只认键值匹配，不比较字段内容新旧
跨数据库类型同步时字段映射怎么处理
当源是 MySQL、目标是 PostgreSQL，或反过来，字段类型不完全对应（比如 MySQL 的 TINYINT(1) 对应 PostgreSQL 的 BOOLEAN），Navicat 不会自动转换。它要么报错中断，要么静默截断/失真。
解决方式是在同步配置的 字段映射 标签页手动调整：点击某一行右侧的“编辑”按钮，在弹窗中修改目标字段名、类型、是否允许 NULL、默认值等。特别注意：
-
TEXT→TEXT可直连，但MEDIUMTEXT到 PostgreSQL 需手动设为TEXT（PostgreSQL 无长度限制） - MySQL 的
DATETIME和 PostgreSQL 的TIMESTAMP WITHOUT TIME ZONE可映射，但时区信息会丢失 - 枚举（
ENUM）和 JSON 类型必须转成字符串（VARCHAR或TEXT）再同步，否则失败
自动化任务执行失败后怎么快速定位问题
自动运行任务失败时，Navicat 默认只在界面右下角弹个提示，不展示具体错误。真正有用的日志藏在 自动运行 窗口底部的 日志 标签页里，而且只保留最近一次执行的完整输出。
关键要看三类信息：
- 出现
ERROR: duplicate key value violates unique constraint：说明主键冲突，某个源数据已由另一源先写入，需检查各源主键是否隔离 - 出现
Column count doesn't match value count：字段映射没对齐，常见于新增字段后没刷新映射配置 - 长时间卡在
Connecting to source...：多半是网络或权限问题，检查目标库连接是否启用了远程访问、用户是否有SELECT权限
复杂点在于：多个同步操作串行执行时，前一个失败不会自动终止后续操作——你得手动在日志里翻到最开头，确认第一个出错点，而不是只看最后一行。
