Navicat结构同步不是一键操作，而是需人工校验的变更发布流程：必须严格区分源库（权威结构，如开发库或Git管理的DDL库）与目标库（待更新环境），禁用默认隐性差异容忍（如字段顺序、注释、字符集），导出可审计SQL脚本而非直接部署，并确保权限、连接配置及客户端版本均适配目标环境。
Navicat 的结构同步不是“推一下就完事”的操作，它本质是一套需人工校验的变更发布流程——跳过比对确认、忽略字段顺序与注释差异、误设源/目标角色，三者任一都会导致生产库结构被错误覆盖。
结构同步前必须锁定源库和目标库角色
源库必须是你已验证过的权威结构来源（比如本地开发库或 Git 管理的 DDL 脚本生成的库），目标库必须是待更新的环境（如测试库或预发库）。常见错误是把测试库当源、生产库当目标去同步，结果把未合入主干的实验性字段直接推到线上。
- 连接别名要带环境标识，例如
DEV_MySQL_OrderDB和STAGING_MySQL_OrderDB，避免右键选错 - 生产环境连接务必启用「只读」选项，除非你明确要执行 ALTER；Navicat 不会阻止你在只读连接上点「开始同步」，但会报权限错误
- 目标库已有数据时，绝对不要勾选
Drop tables；应勾选Drop missing objects in target并提前备份，且确保该选项下生成的每个ALTER TABLE语句都支持在线变更（如 MySQL 5.6+ 的ALGORITHM=INPLACE）
比对设置必须显式关闭隐性差异容忍
Navicat 默认比对只检查对象是否存在，不处理字段顺序、列注释、外键定义顺序、分区规则等隐性差异。如果你依赖默认设置，Structure Synchronization 可能显示“无差异”，但实际两张表的字段顺序不同，后续 ORM 映射或导出 CSV 时就会出问题。
- 在比对窗口中，手动勾选
Compare column order和Compare comments（MySQL/PostgreSQL 支持，SQL Server 需注意兼容性） -
Compare character set必须启用，否则 utf8mb4 和 utf8 的差异会被忽略，后续插入 emoji 时静默失败 - 存储引擎（如
InnoDBvsMyISAM）是否比对，取决于你是否允许跨引擎迁移；若开发用 InnoDB、生产强制要求 MyISAM，则需禁用该选项并手动校验
同步脚本必须导出为可审计的 SQL 文件
直接点击「部署」执行同步，在团队协作中等于放弃变更追溯——没人知道哪条 ALTER 是谁在哪台机器上触发的，也没法回滚单个字段修改。
- 永远先点「部署脚本」而非「部署」，生成的 SQL 文件要包含完整 DDL 变更，并和当前 Git 分支 commit hash 关联存档
- Navicat 生成的脚本默认不含事务包装；若需原子性，得手动加
BEGIN; ... COMMIT;，并确认目标数据库版本支持（如 MySQL 5.7+ 对 DDL 加事务有限制） - .nsx 同步配置文件不包含密码、SSH 隧道、SSL 设置，发给同事前必须用
Data Transfer导出一份含完整建表语句的 SQL，再用Structure Synchronization生成增量脚本，两者合并交付
权限与连接参数最容易被漏检
结构同步失败常报 “Access denied” 或 “Unknown database”，但根源往往不在账号权限本身，而在连接层配置不一致。
- 两个连接的「高级」页里，
Character set必须完全一致（如都设为utf8mb4），否则比对阶段就可能跳过中文字段差异 - MySQL 用户需至少具备
ALTER, CREATE, INDEX权限；PostgreSQL 用户需有CREATE和TEMPORARY权限，且对目标 schema 有USAGE——仅靠ALL ON DATABASE不够 - 跨网络同步（如从办公网连生产 DB）必须启用 SSH 隧道或 SSL，且隧道用户要有对应数据库账号的登录权限；Navicat 不会自动帮你映射隧道用户和 DB 用户
最常被跳过的动作是：没验证源库结构是否真为最新、没检查目标库是否有同名但非预期的临时表、没确认 Navicat 客户端版本是否支持目标数据库的新语法（如 MySQL 8.0 的隐藏索引）。这些点不卡在界面上，但一出错就是线上事故。
