Navicat同步时源表名变更导致“对象不存在”，需先右键源库连接→「从数据库同步」刷新本地模型快照，勾选「忽略不存在的对象」和「跳过已删除的对象」，再预览确认是否误判为DROP+CREATE；若已重命名，应弃用图形向导，改用转储SQL手动替换RENAME语句后执行，并人工更新外键、视图等依赖。
同步时源表名变了，Navicat 报“对象不存在”怎么办
navicat 的结构同步（structure synchronization）不感知外部 ddl 变更，它只比对模型文件（.mmodel）或目标库的当前快照。如果源库表被 rename table 或 alter table ... rename to 改名，而 navicat 仍按旧名去查结构，就会直接报“对象不存在”或“无法匹配表”——这不是连接问题，是元数据脱节。
- 别急着删模型重来，先右键源数据库连接 → 选「从数据库同步」，强制用当前 DB 状态刷新本地模型快照
- 若提示冲突，勾选「忽略不存在的对象」和「跳过已删除的对象」，否则同步流程会中断
- 同步前务必点开「预览」，重点看 Navicat 是否把 rename 识别成了「DROP TABLE 旧名 + CREATE TABLE 新名」——这种误判会连带删掉外键、索引、COMMENT，必须手动干预
为什么「同步到数据库」不会自动修复表名映射
Navicat 结构同步默认按表名自动映射，但这个逻辑发生在「加载阶段」：它读取源库的 INFORMATION_SCHEMA.TABLES（或等效视图）时，拿到的是当前表名；而模型里存的还是旧名，导致两边无法配对。它不会反向查 RENAME 日志，也没有 rename history 表可依赖。
- MySQL 下可通过
SELECT table_name FROM information_schema.tables WHERE table_schema = 'db_name'手动确认当前表名，再比对模型中显示的名称 - PostgreSQL 用户注意：
\dt或pg_tables查出的表名是实时的，但 Navicat 模型若未刷新，仍会沿用旧名参与比对 - 如果源库有大量 rename 操作，建议先导出当前结构为 SQL（右键源库 →「转储 SQL 文件」），再用文本 diff 工具对比模型导出的 SQL，定位差异点
表重命名后同步失败，还能抢救吗
能，但得绕过图形界面。Navicat 不提供 rename-aware 的增量结构同步逻辑，所有 rename 都被当作“删除+新建”处理，风险极高。此时最稳的方式是放弃「结构同步」向导，改用脚本驱动。
- 右键源库 →「转储 SQL 文件」，勾选「仅结构」+「包含 DROP TABLE」，生成干净的建表语句
- 手动编辑 SQL：把
DROP TABLE IF EXISTS old_name改成RENAME TABLE old_name TO new_name（MySQL）或ALTER TABLE old_name RENAME TO new_name（PostgreSQL） - 在目标库执行该 SQL；执行完再右键目标库 →「从数据库同步」更新本地模型，确保后续同步基于新状态
- 外键、视图、存储过程不会被自动重写，必须人工检查并执行对应
ALTER VIEW或ALTER TABLE ... ADD CONSTRAINT
团队协作中多人 rename 表，怎么避免同步打架
.mmodel 是二进制文件，Git 无法 diff，也无法 merge。A 在本地 rename 了 users → user_profiles，B 同时给 orders 加了字段，两人直接同步会覆盖对方变更，且错误提示模糊（只报“同步失败”，不指明哪张表冲突）。
- 禁用共享
.mmodel，统一用「导出为 SQL」代替：右键模型 →「转换为 SQL」，生成可 review 的文本脚本 - 每个 rename 操作单独成脚本，开头加注释标明动作类型与影响范围，例如：
-- [dev_a] RENAME TABLE users TO user_profiles; -- 外键需同步调整 - 上线前在测试库执行脚本，再用「从数据库同步」更新所有成员的本地模型——模型只保留最终态，不记录过程
同步过程中源表已被重命名，本质是 Navicat 缺乏对 DDL 历史的跟踪能力。所有“自动同步”都建立在静态快照比对上，rename 这种破坏性操作必须前置人工确认，不能依赖预览窗口的默认判断。
