Navicat跨库迁移必须使用“数据传输”而非“导入”功能：前者实时连接双库完成迁移，后者仅支持文件导入；MySQL→PostgreSQL等异构迁移需手动配置字段映射、重置序列、强制UTF8编码及禁用autovacuum以避免主键冲突、JSON类型错误和乱码等问题。
navicat 本身不提供“导入数据库”的独立功能，所谓“把一个数据库的数据导入另一个数据库”，实际是通过 数据传输 功能完成的——它不是文件导入，而是实时连接源库和目标库，直接拉取并写入数据。
用 数据传输 而不是 导入 功能
很多人点开目标数据库右键菜单找“导入”，结果找不到对应选项，是因为 Navicat 的“导入”（Import）只支持从外部文件（如 CSV、Excel、SQL 文件）加载数据；而跨库迁移必须用 数据传输（Data Transfer）。这个功能在顶部菜单栏的 工具 里，或右键源数据库时出现。
- 源库和目标库必须都已成功连接，且 Navicat 能同时访问二者（网络连通、账号有读/写权限）
- 如果目标库中已存在同名表，默认行为是覆盖数据（不删表，但会清空再插入），不是追加
- 勾选“结构”选项才会建表；若只勾选“数据”，目标表必须已存在且字段兼容
数据传输 中的表名/字段映射容易出错
当源库和目标库类型不同（比如 MySQL → PostgreSQL），或表名/字段名大小写、下划线风格不一致时，数据传输 可能自动映射失败，导致字段值错位、NULL 填充或报错 column "xxx" does not exist。
- 点击“高级”模式后，在每张表右侧能看到字段映射预览，务必逐个核对源字段 → 目标字段是否匹配
- MySQL 的
TINYINT(1)映射到 PostgreSQL 会变成BOOLEAN，但若目标字段定义为INTEGER，就会报错 - Oracle 表名默认大写，MySQL 默认小写；勾选“转换对象名为大写”可避免
ORA-00942: table or view does not exist
目标库已有数据时，遇到错误继续 很关键
如果目标表有主键或唯一约束，而源数据含重复值，传输中途会卡住并报错 Duplicate entry 'xxx' for key 'PRIMARY'，整个任务就停了。
- 在
数据传输的“高级”设置页，务必勾选遇到错误继续 - 这样出错的行会被跳过，其余数据照常写入，最后日志里会列出所有失败记录供排查
- 若想保留目标库原有数据且只补新增，得手动加条件（如 WHERE updated_at > '2026-07-20'），
数据传输本身不支持 WHERE 过滤
增量同步不能靠 数据传输 自动完成
数据传输 是一次性全量操作，没有内置“上次同步时间戳”或“仅同步变更”逻辑。所谓“增量”，必须自己控制：
- 要么在源库 SQL 查询里加时间条件（如 SELECT * FROM orders WHERE created_at > '2026-07-25'），导出为 SQL 文件后再导入目标库
- 要么用 Navicat 的
数据同步工具（在工具菜单下），它能对比两库差异并生成同步脚本，但要求两库结构严格一致 - 跨库类型（如 MySQL → SQL Server）时，
数据同步不可用，只能靠带条件的查询 + 导出/导入组合
真正麻烦的从来不是点几下鼠标，而是确认源目标字段类型是否真能对上、约束是否允许覆盖、以及出错时有没有留日志可查——这些细节不提前看，传到一半中断，回滚比重来还费劲。
