navicat 17 的“同步到模型”按钮对生产库完全无效，真正可用的是「逆向工程→人工校验→正向工程」三步闭环；该按钮仅在新建模型时响应一次，模型存在后右键表同步即静默，不扫描、不比对、不生成alter语句。
Navicat 17 的“同步到模型”按钮对生产库完全无效，不能用于安全更新表结构；真正可用的路径只有「逆向工程 → 人工校验 → 正向工程」三步闭环，且每一步都必须手动介入。
为什么“同步到模型”在生产环境里等于没点
这个按钮只在新建模型时响应一次，模型一旦存在，右键表→“同步到模型”就彻底静默——它不扫描数据库、不比对字段增删、不识别外键变更，更不会生成 ALTER 语句。生产库上任何 DDL 变更（比如加了个 status 字段或改了 updated_at 类型），该按钮都毫无感知。你点十次，它也不会动生产库一个字节，也不会报错提醒你“此操作不可用”。
安全更新生产库结构的唯一可行流程
必须放弃“一键同步”幻想，走显式、可审计、可回滚的三段式操作：
- 先在 Navicat 中对目标生产库执行「逆向工程」，生成一份全新模型（注意勾选
views、stored procedures等非表对象） - 把新模型与旧模型并排打开，用 Navicat 内置的「比较模型」功能逐项核对差异：重点看
NOT NULL变更、DEFAULT值增减、外键引用是否断裂、索引是否丢失 - 确认无误后，选中差异项 → 执行「正向工程」→ 生成 SQL 脚本 → 绝不直接运行，而是导出为
.sql文件，交 DBA 审核并加入发布流程
容易踩的坑：类型映射失真与权限盲区
跨版本或跨引擎同步时，Navicat 默认类型映射可能埋雷：
- MySQL 8.0 的
TIMESTAMP(6)逆向进模型后，正向工程到 MySQL 5.7 会 silently 降级为TIMESTAMP，精度丢失不报警 - PostgreSQL 的
JSONB字段在模型中显示正常，但正向工程到 SQL Server 会转成NVARCHAR(MAX)，丢失函数支持能力 - 逆向工程需要连接用户对
INFORMATION_SCHEMA有SELECT权限；若生产库启用了行级安全（RLS）或视图重写，部分表可能被跳过且无提示
真正决定安全性的不是按钮，是 SQL 脚本的可控粒度
Navicat 生成的正向工程脚本默认含 DROP ... IF EXISTS 和 CREATE TABLE，这对线上表极其危险。必须手动编辑脚本，把关键变更拆成原子操作：
- 新增字段：改用
ALTER TABLE ADD COLUMN，避免重建表锁表 - 修改字段类型：先
ADD COLUMN new_col，再UPDATE ... SET new_col = old_col，最后DROP COLUMN old_col - 外键添加：确保目标表已有索引，否则
ADD FOREIGN KEY会触发全表扫描
模型只是草图，生产库结构变更的每一行 SQL 都得落在 DBA 的灰度发布清单里——Navicat 不提供 diff 基线、不记录执行时间、不校验变更影响范围，这些空缺只能靠人补。
