Navicat结构同步需确保左侧为待更新库、右侧为基准库，方向错误会导致ALTER脚本反向执行；字段差异须逐项点开DDL比较确认COLLATE、COMMENT等软差异，手动忽略无关项。
结构同步里选错源和目标，字段差异方向就反了
navicat 的结构同步默认以左侧数据库为「待更新方」、右侧为「对齐基准」，但界面只写“数据库1”“数据库2”，不标“源/目标”。一旦拖错顺序，生成的 alter table 脚本会把你想升级的库当成被删字段的一方。
实操建议：
- 确认左侧是你当前要改的那个库（比如
test_old），右侧是你要对齐的新结构库（比如test_new） - 比对完成后，看顶部状态栏是否显示“将对
[左侧库名]应用以下更改”——这是唯一快速验方向的提示 - 发现方向错了别点“部署”，直接关掉重开，重新拖拽顺序
字段类型相同但 COLLATE 不同，Navicat 仍标为“修改”
常见现象：两个字段名、类型、长度完全一致，但 Navicat 标黄色“修改”，点开 DDL 比较 标签才发现只有 COLLATE utf8mb4_0900_as_cs 和 COLLATE utf8mb4_unicode_ci 的区别。这类差异不影响业务，但会触发 ALTER TABLE CONVERT TO CHARACTER SET，可能锁表或引发隐式转换。
实操建议：
- 每条差异项都点开，到底部
DDL 比较标签逐行盯CHARACTER SET、COLLATE、COMMENT、ENGINE - 确认是无关元数据差异后，在对比结果列表中右键该条目 → “忽略此项”
- 批量忽略不支持；Navicat 不按规则自动过滤，必须手动点
无主键表也能比字段，但字段名必须严格一致
结构比对不依赖主键，只解析 SHOW CREATE TABLE 后做语义比对。字段顺序不同、VARCHAR(100) vs VARCHAR(101)、默认值变更都能识别。但 Navicat 不会把 user_id 和 uid 自动对齐——它只按字段名匹配。
实操建议：
- 若两表字段名不一致（如
codevsitem_code），Navicat 无法识别为同一字段，会当成新增+删除处理 - 点击差异项 → 切换到
DDL 比较选项卡，左右并排看完整CREATE TABLE语句，这是最权威依据 - 注意
COMMENT内容差一个空格也会标红，索引字段顺序不一致（如(a,b)vs(b,a)）会被识别为两个不同索引
跨平台比字段时，类型兼容性得人工核
Navicat 数据对比底层靠主键/唯一键做行级匹配，但字段比对本身不校验类型兼容性。比如 MySQL 的 DATETIME 和 PostgreSQL 的 TIMESTAMP WITHOUT TIME ZONE 看似可比，实际隐式转换风险高；SQL Server 的 uniqueidentifier 和 MySQL 的 CHAR(36) 若未启用 UUID 标准化，大小写或连字符位置不同就会误判。
实操建议：
- 进入“工具 → 数据对比”后，手动点击表右侧齿轮图标，在弹窗中显式绑定源库字段和目标库字段（如源
id→ 目标user_id） - 对含 JSON 字段的表，两边需提前用
JSON_NORMALIZE()或jsonb_strip_nulls()处理，否则空格或键序差异会被当作字段值不同 - 时间字段比对前，确认是否勾选了
Compare timestamp with timezone——若一方存 UTC、一方存本地时间，不取消勾选会误报
COLLATE、COMMENT、索引字段顺序这些“软差异”，它们不出现在主列表里，全得靠点开 DDL 比较 才看得见。
