navicat 16 不支持跨 schema 批量自动同步，因其向导仅允许各选一个 source 和 target schema，无通配符或批量选择机制；需通过重复任务+profile 复用或脚本驱动实现多 schema 同步。
Navicat 16 不支持跨 Schema 的“批量自动同步”——它没有内置的 Schema 批量遍历或通配符匹配机制，必须手动为每对 Source→Target Schema 单独配置任务。想一次操作同步多个 Schema，得靠组合策略绕过限制。
为什么不能直接选多个 Schema 同步
Navicat 的 Data Synchronization 和 Data Transfer 向导在 Step 1 中只允许各选「一个」Source 数据库（即一个 Schema）和「一个」Target 数据库（即一个 Schema）。即使你连接的是 MySQL 或 Oracle，它也不会把 information_schema 或 ALL_USERS 当作可同步对象；Schema 是顶层作用域，不是可勾选的子项。
常见错误现象包括：右键点击连接名 → “数据传输” → 勾选多个数据库 → 实际只生效第一个；或在 Oracle 连接中展开多个用户（如 SCOTT、HR），但向导里无法多选它们作为 Source。
- Navicat 把 Schema 视为独立迁移单元，不提供
--all-schemas类命令行语义 - Oracle 模式（user）和 MySQL database 在 Navicat 内部模型中均映射为单个
database对象，无集合操作接口 - 试图用通配符命名 Schema（如
prod_%）会直接报错Unknown database
用「重复任务 + Profile 复用」实现准批量
最稳定的做法是为每对 Schema 创建独立同步任务，再通过保存/加载 Profile 加速重复配置：
- 先完成一对 Schema（如
order_dev→order_test）的完整同步配置：设好键映射、字段过滤、Insert/Update/Delete 策略 - 点【Save Profile】存为
order_sync.nps（注意勾选Include connection settings） - 新建任务 → 【Load Profile】载入该文件 → 在 Step 1 中手动切换 Source 为
user_dev、Target 为user_test - 重新执行
Compare&Preview—— 因表结构可能不同，键映射需二次确认，但其余选项（如更新策略、字段排除规则）已复用
这个流程把单次配置时间从 5 分钟压到 90 秒内，适合 3–5 个 Schema 的常规场景。超过 5 个建议改用脚本驱动。
Oracle 用户间同步要预建空 Target Schema
Oracle 的 Data Transfer 在跨用户（Schema）同步时，不会自动创建目标 user，且默认不执行 CREATE USER。若 Target Schema 不存在，会卡在“正在创建表”并报 ORA-01918: user 'XXX' does not exist。
- 必须提前用 DBA 账号执行：
CREATE USER target_user IDENTIFIED BY pwd;+GRANT CREATE SESSION, CREATE TABLE, UNLIMITED TABLESPACE TO target_user; - Navicat 的【高级】页中勾选
Convert object names to uppercase，避免因大小写导致ORA-00942: table or view does not exist - 若源 Schema 含同义词（synonym）或物化视图（materialized view），
Data Transfer默认不处理，需单独用Structure Synchronization补充
MySQL 多 database 同步的隐藏风险
MySQL 虽然用 database 代替 Schema，但 Navicat 对跨 database 同步有更隐蔽的约束：
- 若 Source 和 Target 使用不同
sql_mode（如 Source 是STRICT_TRANS_TABLES，Target 是空），INSERT可能因隐式类型转换失败，错误信息被吞掉，只显示“同步完成 0 行” - 字符集不一致时（如 Source 是
utf8mb4_0900_as_cs，Target 是utf8mb4_general_ci），中文字段可能变成???，且 Navicat 预览界面不提示编码警告 - 使用
mysqldump导出再导入虽绕过 Navicat，但会丢失 Navicat 特有的同步状态记录（如上次同步时间戳、冲突日志），不利于后续增量比对
真正需要高频跨 Schema 同步的团队，最终都转向了 SQL 脚本 + 定时任务组合：用 Navicat 生成首版 DDL/DML，再用 mysql -h -u -p -e "source sync_order.sql" 批量执行，把控制权拿回来。
