Navicat结构同步如何避免误删生产环境数据

“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 字段用于多租户测试。如果结构同步时没有人工审核和干预，这个字段就很可能被直接删除。