Navicat 本身不提供自动 DDL 变更日志功能，仅支持导出当前表结构的只读 DDL 快照；真正可追溯的变更需依赖手动导出、Git 管理 SQL 文件或数据库审计日志（如 MySQL general_log 或 audit_log）。
Navicat 本身不提供自动 DDL 变更日志功能
navicat 是图形化数据库管理工具，不是版本控制或变更审计系统。它不会像 pt-online-schema-change 或 flyway 那样自动捕获、记录或回滚表结构变更。你手动执行的 alter table、create table 等操作，navicat 不会默认写入本地日志文件或生成变更快照。
手动导出 DDL 是最可靠且通用的做法
每次修改表结构后，立刻导出当前表的完整 DDL，是实际项目中最可控、零依赖的记录方式。Navicat 提供了便捷入口，但要注意几个关键点：
- 右键点击表 → “对象信息” → 切换到 “DDL” 标签页，这里显示的是 Navicat 根据元数据反向生成的语句，**不是你上次执行的那条 ALTER 命令**，而是当前结构的“最终态”定义
- 导出前确认连接的是目标环境（开发/测试/生产），避免误导出错库的表结构
- 建议将导出文件按
table_name_YYYYMMDD_HHMMSS.sql命名，并存入与项目代码同级的schema/目录下，方便追溯 - 如果使用 MySQL，注意 Navicat 生成的 DDL 可能含引擎参数（如
ENGINE=InnoDB）、字符集（CHARSET=utf8mb4）和注释（COMMENT），这些都属于结构的一部分，别手动删掉
用查询日志 + 审计插件辅助还原变更过程
仅靠 DDL 导出只能知道“结果”，不知道“怎么变的”。若需复盘某次变更的具体步骤（比如加字段+改类型+删索引），得依赖数据库自身的日志能力：
- MySQL 开启
general_log（仅限开发/测试环境！生产慎用）：SET GLOBAL general_log = 'ON';<br>SET GLOBAL general_log_file = '/path/to/general.log';
然后在 Navicat 中执行操作，之后 grep 匹配表名和时间范围 - MySQL 8.0+ 可启用
audit_log插件，记录所有 DDL 语句，但需管理员权限安装配置 - PostgreSQL 可配合
pg_audit扩展，或直接查pg_stat_operations（需开启track_counts = on） - Navicat 自身的“运行历史”窗口（菜单栏：工具 → 运行历史）只保存当次会话的 SQL，关闭即清空，不可靠
真正需要结构变更可追溯？绕过 Navicat 直接上迁移工具
如果你团队频繁修改表结构、多人协作、还要上线审批，硬靠 Navicat 手动导出+日志拼凑，迟早丢变更、踩冲突。这时候该让专业工具接管：
- Flyway 或 Liquibase：把每次变更写成带编号的
V1_2__add_user_status.sql或changelog.xml，Navicat 只作为执行终端之一 - 所有 DDL 必须走脚本，禁止在 Navicat 里点“设计表”直接改 —— 因为那种方式不会生成可版本化的 SQL
- Navicat 的“数据传输”或“结构同步”功能可用于比对差异，但同步前务必勾选 “生成 SQL 脚本而不执行”，否则容易漏审
最常被忽略的一点：Navicat 导出的 DDL 默认不含 IF NOT EXISTS 或 DROP TABLE IF EXISTS，直接用于重建会报错；而迁移工具生成的脚本通常自带幂等逻辑。这点在自动化部署时尤为关键。
