Navicat同步模型报错主因是本地缓存与数据库结构不一致，权限不足、SQL模式不兼容、表名含特殊字符或版本不匹配均会导致解析失败、语法错误或数据丢失。
Navicat 同步模型报错：提示 “Table ‘xxx’ doesn’t exist” 或语法解析失败
这是最常见的情况——你改了数据库（比如重命名表、删字段、加索引），再点「同步到模型」，navicat 却报错说找不到表，或者卡在「正在解析 sql」然后崩溃。根本原因不是模型丢了，而是 navicat 的本地模型缓存和实际数据库结构不一致，且它默认用 show create table 或 information_schema 查询来反向生成 ddl，一旦权限不足、sql 模式不兼容（如 mysql 8.0+ 的 sql_mode=strict_trans_tables）、或表名含特殊字符（空格、短横线），就容易解析失败。
- 检查当前连接用户是否对
INFORMATION_SCHEMA有SELECT权限；没权限时 Navicat 会静默降级，但可能漏读约束，导致后续建模出错 - 如果表名含短横线（如
user-log），Navicat 有时会误解析成减法表达式；务必确认建模时该表在模型里显示为带反引号的`user-log`，否则同步时生成的 DDL 缺失引号，直接报语法错误 - MySQL 8.0+ 默认开启
sql_mode=ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,...，而 Navicat 旧版本（≤16.0）生成的解析 SQL 可能不兼容 STRICT 模式，临时解决可执行：SET sql_mode = '';再同步（仅会话级，不影响生产）
同步后模型里字段顺序错乱、主键丢失、外键消失
Navicat 不是靠“对比差异”做增量更新，而是全量重建模型结构——它把数据库当前状态当唯一事实源，重新拉一遍元数据，再覆盖本地模型。所以如果你手动在模型里调整过字段顺序、加过注释、标过逻辑外键（非物理外键），这些都会被清空。
- 物理外键（
FOREIGN KEY约束）必须存在于数据库中，Navicat 才能读取并映射；只在模型里画了连线 ≠ 数据库有约束 - 字段顺序由
INFORMATION_SCHEMA.COLUMNS.ORDINAL_POSITION决定，但某些视图或临时表该字段不可靠；若发现顺序总不对，可导出数据库 DDL（mysqldump --no-data），用文本比对确认真实顺序 - 主键丢失通常是因为原表用了联合主键但其中某个字段被设为
NULL，MySQL 允许但 Navicat 解析时可能忽略；检查SHOW KEYS FROM table_name WHERE Key_name = 'PRIMARY'输出是否完整
点击「同步到数据库」时报错：Syntax error near ‘TYPE=InnoDB’ 或 ‘ENGINE=InnoDB ROW_FORMAT=DYNAMIC’
这是模型和目标数据库版本不匹配的典型症状。Navicat 模型保存的是抽象语法（比如它默认写 TYPE=InnoDB），而新版本 MySQL 已废弃 TYPE，只认 ENGINE；同样，老版本 Navicat 不认识 ROW_FORMAT、STATS_PERSISTENT 这类 5.7+ 新参数。
- 在 Navicat 中打开模型 → 右键表 → 「编辑表」→ 切到「选项」页，把
Engine显式设为InnoDB，并清空所有数据库特有字段（如ROW_FORMAT、STATS_AUTO_RECALC），让 Navicat 用目标版本默认值生成 DDL - 若目标库是 MySQL 8.0+，确保 Navicat 版本 ≥ 16.1（支持 8.0 元数据格式）；低于此版本同步时会把
utf8mb4_0900_as_cs排序规则自动降级为utf8mb4_general_ci，导致后续 DDL 执行失败 - 避免在模型里手动编辑 DDL 预览框里的语句——Navicat 同步逻辑不校验你改的内容，直接照搬执行，极易因少个逗号或引号引发语法错误
为什么改了数据库后，Navicat 模型里看不到变更？必须重启才刷新
Navicat 的模型编辑器不是实时监听数据库变化的，它的「同步」动作依赖一次完整的元数据抓取流程，而这个流程会被本地缓存、连接复用、甚至 UI 线程阻塞干扰。最常被忽略的一点是：你改完数据库后，没主动断开再重连当前连接。
- 右键连接 → 「断开连接」→ 再右键 → 「连接」，强制刷新连接上下文，否则 Navicat 可能继续用旧的
TABLES缓存结果 - 如果用了 SSH 隧道或代理，网络延迟可能导致元数据查询超时，Navicat 默默返回空结果却不报错；此时看底部状态栏是否显示「Fetching table structure…」长时间不动，就该怀疑网络层问题
- 模型文件（
.nsx）本身是二进制，不建议用外部工具编辑；曾有人用文本编辑器改了里面表名，导致下次打开直接报「Invalid model file」——这种损坏无法恢复，只能从数据库重新同步
模型同步本质是元数据搬运，不是智能 diff。它不会告诉你「这个字段类型从 VARCHAR(50) 改成了 VARCHAR(100)」，只会按当前状态覆盖。真正要追踪变更细节，得靠数据库自身的 information_schema 快照比对，或者用 Flyway/Liquibase 这类迁移工具管理 DDL 历史。
