“PROD → DEV”这个同步方向不要直接点击 Run。原因很明确：当 Na vicat 将生产库作为源、开发库作为目标时，生成的 SQL 通常会包含 DROP 语句，进而把开发库中那些生产库里不存在的对象一并删除，例如测试表、临时字段、调试索引等。更安全、稳妥的做法是：务必关闭“Drop objects not exist in source”和“Compare auto-increment value”这两个选项，只生成并保存 SQL 文件，先进行人工审核，确认没有风险后再执行。
结构同步时为什么“PROD → DEV”方向不能点 Run
Na vicat 的数据库结构同步功能并不会理解“上线发布”还是“数据回灌”这类业务场景，它只会识别左右两侧谁是「源」、谁是「目标」。一旦把生产库放在源端、开发库放在目标端，它的默认策略就是：尽可能让目标库与源库保持完全一致。结果往往就是系统直接生成 DROP TABLE、DROP COLUMN 等危险语句，把目标库中那些源库不存在的对象全部删除。问题也正出在这里——开发库通常本来就会比生产库多出一些测试表、临时字段、调试索引或实验性结构，这些内容在结构同步时极有可能被顺带清理掉。
常见错误现象包括：
- 执行后本地
dev_user_log表被删除，导致单元测试或集成测试批量失败 - 开发库中手动新增的
is_debug TINYINT DEFAULT 0字段被移除，应用启动时报“列不存在”错误 - 同步过程中因权限不足中断，部分
ALTER TABLE已执行、部分未执行，最终使环境进入半完成、半损坏状态
必须关闭的两个高危选项
在结构同步向导的「Compare options」页面，这两个选项如果不取消，基本等于主动放开删表删字段的风险：
Drop objects not exist in source：勾选后将允许删除目标库中源库不存在的表、字段和索引，生产相关同步场景中应严格禁用Compare auto-increment value：勾选后可能导致目标库主键自增值被重置，后续插入数据时有概率触发主键重复冲突
其他也可根据实际情况关闭的选项包括：Compare comments（注释差异容易出现误报）、Compare collation（字符集或排序规则不一致时容易引发 SQL 语法或兼容性问题）。
正确交付流程：只生成 SQL，不自动执行
真正的目标不是让 Na vicat 直接改库，而是利用它生成一份可审计、可复核、可复现的数据库结构变更 SQL。推荐操作步骤如下：
- 左侧面板选择
PROD_MySQL_OrderDB（源），右侧面板选择DEV_MySQL_OrderDB（目标） - 点击「比较」后，**绝对不要直接点击「Run」**，而是选择「Sa ve as SQL File」，保存为
prod_struct_20260727.sql - 交付前进行人工审查：删除所有
DROP与RENAME语句，补齐NOT NULL字段默认值（Na vicat 往往不会自动补全），同时核对CHARSET与实际字段长度是否一致 - 开发团队接收后，只提取
CREATE TABLE或ALTER TABLE ... ADD COLUMN这类相对安全的语句，先在本地测试库验证通过，再应用到目标环境
同步前必须确认的三件事
如果跳过下面这三项检查，最终生成的 SQL 很可能无法顺利执行，甚至会造成结构同步失败：
- 确认源库与目标库的 MySQL 版本兼容（例如
JSON字段无法从 8.0 直接同步到 5.6） - 确认连接用户在目标库拥有
ALTER、CREATE等必要权限（如果只有SELECT权限，变更可能被静默跳过） - 确认目标库中是否存在同名但已被人工修改过的表结构（Na vicat 通常不会提示冲突，而是直接按差异覆盖）
最容易被忽视的往往是最后一点：例如一张名为 audit_log 的表，在生产库中是标准建模结构，而开发库中却可能被额外增加了 tenant_id 字段用于多租户测试。如果结构同步时没有人工审核和干预，这个字段就很可能被直接删除。
