Navicat 不保存结构同步历史记录，仅提供单次会话内不可持久化的信息日志；可靠变更追踪需结合 Git 管理差异 SQL 脚本、脱敏配置及建模文件，并严格执行备份与二次比对验证。
Navicat 本身不保存结构同步历史记录
navicat 没有内置的「结构同步操作日志」或「变更历史面板」——你执行完 结构同步 向导后，界面关闭，过程就结束了。它不会像 git 那样记录哪次改了哪张表、谁在什么时候执行了什么 ddl。所谓“历史”，只能靠你自己留痕。
唯一可查的日志是单次同步的执行结果
每次点击 运行查询 后，Navicat 会在当前向导窗口底部打开 信息日志 标签页，显示刚执行的 SQL 语句和执行结果（如 ALTER TABLE `user` ADD COLUMN `status` TINYINT、OK: 1 row(s) affected）。但这个日志只存在于本次向导会话中，关掉窗口就消失，也无法导出为文件。
- 想保留它？必须手动全选日志内容 →
Ctrl+C复制 → 粘贴到记事本或 Markdown 文件里存档 - 别依赖截图：DDL 语句长时容易截不全，且无法搜索/比对
- 如果勾选了
运行后对比（推荐），日志里还会包含二次比对结果，能看出是否真同步干净了
真正可靠的变更追踪得靠外部手段
把结构变更当代码管，才是生产环境该有的姿势。Navicat 只是个执行工具，不是版本控制系统。
- 每次同步前，用
工具 → 结构同步的「比对」功能生成差异脚本，先保存为.sql文件（比如v2.3.0-20260310-ddl.sql），再运行 - 把这些 SQL 文件纳入 Git 管理，提交时写清楚变更原因（如「增加 user.last_login_at 字段，支持登录统计」）
- 数据库连接名、库名、甚至 Navicat 的
同步配置文件（.ncf）也可以存进仓库，但注意脱敏密码 - 如果团队共用一套结构，建议统一用
Navicat Data Modeler建模，模型文件本身就能 diff 和版本化
容易被忽略的关键点
很多人同步完就以为万事大吉，但最危险的不是没日志，而是没验证。
-
运行查询成功 ≠ 表结构真的和源库一致：某些 DDL（如修改列顺序、注释）可能被 Navicat 忽略或静默跳过，务必手动DESCRIBE table_name或用「比对」再扫一遍 - 带数据的表做
ADD COLUMN ... NOT NULL同步时，Navicat 默认填DEFAULT值，但如果你没设默认值，就会报错中断——这种细节不会出现在日志摘要里，得盯紧信息日志的完整输出 - 千万别跳过备份：Navicat 的
备份按钮就在主工具栏，同步前点一下，生成.nbu文件，几秒的事。真出问题时，这比翻日志快十倍
