结构同步比直接导出SQL更稳，因其专为结构一致性设计，逐对象比对、生成可预览DDL脚本，并支持跳过已存在对象、忽略注释等精细控制；操作前需确认源/目标库连通且目标账号具备CREATE/ALTER/DROP权限，勾选“执行前备份目标对象”，跨库迁移时须人工核对字段类型、字符集、schema及语法差异。
用“结构同步”工具比导出SQL更稳
直接导出 sql 再导入，容易漏掉索引、外键、默认值或字符集设置；而 结构同步 是专为结构一致性设计的，它会逐对象比对、生成可预览的 ddl 脚本，并支持跳过已存在对象、忽略注释等精细控制。
操作前先确认：源库和目标库都连得通，且目标库账号有 CREATE、ALTER、DROP 权限；如果目标库已有同名表，Navicat 默认不会覆盖，需手动勾选“删除目标对象”或“跳过已存在对象”。
- 在 Navicat 中点击 工具 → 结构同步
- 左侧设为源数据库（含完整结构），右侧设为目标数据库
- 进入比对后，界面会高亮显示差异项（比如某张表缺主键、某个字段类型不一致）
- 点击“部署脚本”页签，可编辑生成的 SQL —— 例如把
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4改成目标库实际支持的字符集 - 务必勾选“在执行前备份目标对象”，尤其当目标库已有数据时
跨数据库类型迁移时，字段类型必须人工核对
MySQL 的 TINYINT(1) 在 PostgreSQL 里会被转成 smallint，Oracle 则可能变成 NUMBER(1)；TEXT 类型在 SQL Server 中对应 NVARCHAR(MAX)，但 Navicat 不会自动加 N 前缀，导致中文乱码。
这类转换不是 Navicat 的 bug，而是底层方言差异。不能依赖“自动转换”选项完事，得打开比对结果，逐个点开表 → 字段 → 类型栏，对照目标库文档确认是否兼容。
- 特别注意：
auto_increment（MySQL）→serial（PostgreSQL）→IDENTITY（SQL Server），三者语法和约束行为完全不同 - 时间类型也常出错：
DATETIME在 Oracle 里没有直接等价类型，Navicat 可能硬转成DATE，丢失毫秒精度 - 如果发现字段类型被转成
UNKNOWN或OTHER，说明 Navicat 无法映射，必须手动在部署脚本里重写该字段定义
导出“仅结构”SQL 适合留档或二次加工
当你需要把建表语句交给 DBA 审核、纳入 Git 版本管理、或准备在不同环境批量执行时，转储SQL文件 → 仅结构 是最轻量可控的方式。
但要注意 Navicat 默认导出的 SQL 里可能包含连接上下文信息（如 USE `db_name`;），如果目标库名不同，这条语句会导致后续建表失败；另外，部分版本导出的外键语句不带 CONSTRAINT 名，导入时可能报重复约束错误。
- 导出前，在“高级”选项里取消勾选“添加 USE 语句”
- 导出后打开 SQL 文件，搜索
FOREIGN KEY，手动给每个补上唯一约束名，例如：CONSTRAINT fk_user_order FOREIGN KEY (user_id) REFERENCES user(id) - 若目标库是 PostgreSQL，记得把 MySQL 的反引号
`全部替换成双引号"，否则解析失败
别忽略模式（schema）和搜索路径的影响
PostgreSQL 和 SQL Server 都有 schema 概念，MySQL 5.7+ 也支持（虽常被忽略）。Navicat 在导出或同步时，是否带上 schema 名，取决于你连接时指定的默认 schema，以及导出选项里的“导出对象名是否带 schema 前缀”。
常见现象：源库表在 public schema 下，目标库连接默认 schema 是 dbo，结果 Navicat 把表建到了 dbo 下，但外键引用仍指向 public.table_name，导致后续查询报错。
- 连接 PostgreSQL 时，右键连接 → “连接属性” → “高级”页签，检查“默认 schema”是否设为
public（或你实际用的 schema） - 在结构同步向导的“高级”设置里，勾选“导出对象名带 schema 前缀”，并确保目标库中该 schema 已存在
- SQL Server 用户注意：
CREATE TABLE dbo.user和CREATE TABLE user效果不同，后者会建在当前用户默认 schema 下，极易混乱
WARNING: column type mismatch 这类提示——它不会中断流程，但大概率会在上线后咬你一口。
