结构同步前必须确认三件事：一是目标库账号权限仅含select和alter，禁用drop/create；二是生产环境连接必须启用ssl；三是将高级选项中“超时时间”调至≥120秒，避免大表比对中断导致脚本执行不全。
结构同步前必须确认的三件事
没做这三步就点“比较”，90%的概率会在生产库上执行意外 DROP TABLE 或 ALTER COLUMN。不是危言耸听，是 Navicat 默认行为本身就会生成高风险语句。
第一，确认目标库连接账号权限只含 SELECT 和 ALTER，绝不能有 DROP、CREATE（除非你明确要建新表）；第二，检查连接属性里是否启用了 SSL（生产环境必须开）；第三，在“高级”选项卡中把“超时时间”从默认 30 秒调到至少 120 秒——大表结构比对容易超时中断，中断后脚本可能只执行了一半。
- 连接别名建议带环境标识，比如
PROD_order_db、DEV_order_db，避免左右选反 - 字符集必须勾选“启用比较”，否则
utf8mb4和utf8差异会被忽略，后续插入中文直接报错 - 存储引擎差异（如源库是
InnoDB，目标库是MyISAM）不勾选“比较”也行，但得心里有数
比对结果里哪些标记代表高风险操作
Navicat 的比对界面用颜色和符号表达语义，但新手常误读。红色“−”不是“删掉这个字段”，而是“目标库缺少这个字段”，它会生成 ADD COLUMN；真正危险的是蓝色“x”出现在目标对象列——那意味着 Navicat 计划在目标库执行 DROP TABLE 或 DROP INDEX。
特别注意黄色警告三角：比如源字段是 VARCHAR(255)，目标是 VARCHAR(50)，它不会标红，但会提示“可能截断数据”。这种变更一旦执行，超出长度的值会被无声截断，查不到日志，业务侧才第一个发现异常。
- 看到操作列为
x（删除）或→（替换）且对象是整张表，立刻停手，检查是不是连错了目标库 -
DEFAULT值变更、NOT NULL约束增减，都属于“无提示但有破坏性”的操作，务必点开 DDL 比较看生成的 SQL - 视图、存储过程的结构同步默认不包含依赖检查，如果目标库缺基础表，同步后视图会变成无效状态
部署脚本前必须手动干预的两个环节
Navicat 生成的部署脚本不是“拿来即跑”的最终答案，它是草稿。直接点“运行”等于把控制权交给算法，而算法不知道你的业务约束。
第一步，进“部署脚本”选项卡，点击右下角“部署选项”，务必取消勾选“遇到错误时继续”——否则一个 ADD COLUMN 失败，后面几十条语句照常执行，最后发现表结构七零八落。
第二步，点击“编辑脚本”，手动调整顺序：所有 ADD COLUMN 放最前，所有 MODIFY COLUMN 居中，所有 DROP COLUMN 放最后（且建议删掉，改用 RENAME COLUMN 或分步处理）。
- 如果脚本里出现
ALTER TABLE ... DROP PRIMARY KEY，不要执行，先确认是否真需要去掉主键 - 涉及大字段（如
TEXT、BLOB）类型变更，MySQL 会锁表，务必安排在低峰期，并提前在测试库验证耗时 - 点击“复制脚本到剪贴板”后，建议粘贴到外部编辑器里搜索
DROP、RENAME、MODIFY，逐行评估
为什么备份不能跳过，以及怎么备才有效
很多人觉得“只是改个字段，又不删数据，备什么份”，结果 ALTER TABLE 执行一半磁盘满了，整个表卡在不可读状态。Navicat 自带的备份功能能导出结构+数据，但对结构同步场景来说，它太重了——你只需要结构快照。
更轻量、更可控的方式是：在结构同步前，用 Navicat 打开目标库，右键数据库 → “转储 SQL 文件” → 勾选“仅结构”，保存为 prod_schema_before_sync.sql。这个文件几 KB，秒级完成，而且可 git 提交、可 diff、可快速回滚。
- 不要依赖 Navicat 的“自动备份”开关，它只在执行失败时触发，成功执行后不会留痕
- 如果目标库已有重要数据，同步前用命令行再确认一次：
mysqldump -h host -u user -p --no-data prod_db > schema_backup.sql - 同步完成后，别急着关窗口，先点“信息日志”看有没有黄色警告（比如“索引未创建，因重复名存在”），这类问题不会报错但会影响查询性能
