“部署到”按钮不能直接点，因其自动执行全部DDL脚本，不校验主从延迟、外键依赖、字符集兼容性，且可能遗留临时对象；须导出SQL人工审查，重点检查DROP/MODIFY语句，补全字符集，低峰期执行并确认复制延迟≤1秒。
别直接点“部署到”——它默认执行所有生成的 ddl，包括 drop column、drop table 等高危操作，且不校验主从延迟、外键依赖或字符集兼容性。
为什么“部署到”按钮不能直接点
Navicat 的 Deploy to 功能本质是自动执行比对后生成的全部 DDL 脚本，但它的执行逻辑不包含生产环境必需的安全检查：
- 不等待从库复制完成：主库执行
ALTER TABLE后，从库可能卡在 1236 错误（Got an error reading communication packets） - 不解析外键依赖链：若脚本含
MODIFY COLUMN但该列被外键引用，MySQL 直接报错ERROR 1845 (HY000) - 不继承源列字符集：新增字段若未显式声明
CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs，会按库级默认值（如utf8mb4_general_ci）创建，后续JOIN或ORDER BY可能隐式转换失败 - 忽略临时状态残留：中断执行后，Navicat 可能遗留
_old表或临时触发器，下次比对会误判为新对象
必须手动导出并审查 SQL 脚本
安全同步的前提是把 DDL 从自动执行环节中“拽出来”，交由人工控制节奏和上下文：
- 在结构比对界面点击
Save SQL File...，不要点Deploy to - 打开生成的 .sql 文件，重点检查以下三类语句：
DROP COLUMN、DROP TABLE、MODIFY COLUMN—— 这些几乎都需前置验证或改写 - 对含外键的表，手动拆分脚本：先
DROP FOREIGN KEY，再MODIFY COLUMN，最后ADD CONSTRAINT；Navicat 不保证顺序 - 所有
ADD COLUMN语句末尾补全字符集与排序规则，例如：ADD COLUMN nickname VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs
低峰期执行前的关键检查项
即使脚本已人工审查，上线窗口仍需确认运行时环境是否就绪：
- 用
SHOW SLAVE STATUS\G（MySQL）或pg_stat_replication（PostgreSQL）确认从库延迟 ≤ 1 秒 - 检查目标库当前连接数：
SHOW PROCESSLIST，避免锁表期间被长事务阻塞 - 禁用应用端写入：通过配置中心关闭订单/支付等核心写入口，而非仅靠数据库权限控制
- 执行前手动备份单表结构：
SHOW CREATE TABLE users\G，比 Navicat 备份更快、更轻量
真正容易被忽略的不是语法错误，而是“变更被当作一次性操作执行”——DDL 在 MySQL 中多数不可回滚，一旦 ALTER TABLE 开始重建聚簇索引，中断也会留下半成品表。所以每条语句都得当成独立发布单元来设计执行条件和回退路径。
