结构同步前必须手动验证连接可用性、源目标顺序不可颠倒、绿色加号与红色减号须逐条核对，且比对后必须人工审查SQL脚本，避免DROP、NOT NULL等高危操作引发生产事故。
结构同步前必须手动验证两个连接是否真实可用
很多“比对无结果”或“跳过某些表”的问题，根源不是 navicat 功能失效，而是连接本身不可靠。navicat 的结构比对依赖完整读取 information_schema 和执行 show create table，一旦权限不足、网络抖动或数据库禁用了元数据查询，就会静默失败。
实操建议：
- 在开发库连接里执行：
SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'your_db_name';，记下返回数 - 在生产库连接里执行同样语句，确认数量一致
- 挑 1–2 个典型表（如
t_user），分别运行：SHOW CREATE TABLE `t_user`;，看是否返回完整建表语句（注意反引号不能丢） - 若开发库是 Docker MySQL 实例，检查是否启用了
information_schema：运行SELECT @@sql_mode;，确认不含NO_TABLE_OPTIONS或类似限制项
源库和目标库顺序绝对不能颠倒
Navicat 结构同步不是双向 diff 工具，它只生成「从源 → 目标」的单向 DDL 脚本。把生产库设为源、开发库设为目标，等于让 Navicat 把线上旧结构反向覆盖到开发环境——这和你想“把开发最新结构推到生产”完全相反。
正确做法：
- 想把开发新字段/索引/约束上线 → 开发库是 源，生产库是 目标
- 目标连接名必须带明确环境标识，例如
PROD_OrderDB，别用模糊名如order_db - 在连接属性中给生产库设置红色标签（外观 → 颜色），视觉上形成强警示
绿色加号和红色减号必须逐条人工核对
左侧（源）显示开发库当前状态，右侧（目标）显示生产库当前状态。绿色加号表示“开发有、生产无”（如新增了 is_deleted TINYINT(1)），红色减号表示“开发删了、生产还有”（如开发已 DROP COLUMN old_desc）。
容易踩的坑：
-
TINYINT(1)和BOOLEAN被标为不一致：MySQL 底层等价，但 DDL 输出不同。新版 Navicat 17 可在Options > Compare settings中勾选Ignore tinyint(1) vs boolean - 字段顺序不同被误判为「删+增」：在
Options页勾选Ignore column order - 黄色警告提示「可能截断」：如开发是
VARCHAR(200)，生产是VARCHAR(50)，必须先查实际数据长度：SELECT MAX(CHAR_LENGTH(column_name)) FROM table_name;，再决定是否扩列
比对后导出 SQL 前务必人工审查变更脚本
Navicat 生成的同步脚本默认包含 DROP、ALTER、CREATE 等高危操作，尤其是涉及主键、外键、索引或大字段修改时，直接执行可能锁表或阻塞业务。
关键检查点：
- 确认所有
DROP COLUMN操作对应字段确已下线，且生产数据中该列值全为 NULL 或可安全丢弃 - 检查
MODIFY COLUMN是否含隐式类型转换（如VARCHAR→TEXT），这类操作在 MySQL 中可能触发全表重建 - 留意脚本中是否混入了
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4等全局变更，避免意外修改表级字符集 - 对生产环境，建议将脚本拆分为多个小批次执行，并在低峰期操作
最常被忽略的点：比对界面里看似“干净”的绿色加号，可能对应一个未被测试覆盖的新增 NOT NULL 字段——如果目标表已有数据，同步会因缺少 DEFAULT 值而失败。这种细节不会在比对结果里高亮，只能靠人工看建表语句和目标表数据现状交叉判断。
