结构同步前必须手动取消勾选 DROP COLUMN 和“Drop objects not exist in source”选项，否则会误删字段、表、索引；预览SQL需重点核查 MODIFY/CHANGE 语句、COMMENT/DEFAULT 是否丢失，并确认权限与字符集配置。
结构同步前必须手动取消勾选 DROP COLUMN
navicat 默认对比出所有差异项并全选，包括字段删除操作。只要源库某张表里删了一个字段，目标库对应表的该字段就会被 drop column —— 这在生产环境等同于数据丢失。
- 点击「对比」后，立即检查差异列表中是否有带
DROP COLUMN的行，**必须手动取消勾选** - 别信“我只是同步新增字段”——只要源库结构有删字段动作，Navicat 就会生成删除语句
- 如果目标库该字段存有业务数据（比如历史日志字段），执行后无法恢复，且 Navicat 不校验字段是否为空或被索引依赖
为什么勾选了“Drop objects not exist in source”就等于开闸放水
这个选项控制的是整个对象层级：勾选后，不仅删字段，还会删表、删索引、删视图。它不是按需触发，而是全局开关。
- 该选项默认是勾选状态，但上线前必须确认为**未勾选**
- 一旦勾选，且源库某个表被重命名或临时移除，Navicat 会在目标库直接执行
DROP TABLE - 它不区分“开发误删”和“正式下线”，只要源库元数据里没了，目标库就跟着删
预览 SQL 时重点盯住 ALTER TABLE MODIFY 和 CHANGE 的字段顺序
Navicat 有时会把字段修改识别成“先删后加”，本质是字段顺序变动触发了隐式重建。这种行为容易掩盖真实意图，甚至导致字段注释、默认值、NOT NULL 约束一并丢失。
- 预览页看到
ALTER TABLE ... MODIFY COLUMN多次出现，尤其伴随字段名重复或位置偏移，说明 Navicat 把结构调整误判为删除重建 - 检查生成语句中是否遗漏了
COMMENT或DEFAULT子句——这些不会报错，但静默失效 - 若发现字段类型没变、仅顺序调整，建议改用人工
ALTER TABLE ... CHANGE COLUMN显式重排，避免意外丢约束
字段被“漏同步”不一定是工具问题，很可能是权限或字符集卡住了
有时候你以为字段没同步成功，其实是 Navicat 根本没读到源库的字段定义，自然不会比对、也不会生成语句。
- 确认连接用户对
information_schema.columns有 SELECT 权限；否则column_comment、is_nullable等关键字段返回 NULL - MySQL 连接字符集设为
latin1或utf8（非utf8mb4）时，含中文注释的字段可能被解析为空，导致字段“看起来不存在” - Navicat 12 及更早版本对 MySQL 5.6 的
column_comment支持不稳定，升级到 Navicat 16+ 可缓解
