Navicat桌面版无法独立完成变更审计，因其本地操作历史不共享、无执行上下文、不关联工单、不拦截高危操作；必须启用Navicat On-Prem Server才能实现集中日志、权限管控、同步任务共享与合规追溯。
Navicat 本身不内置数据库变更日志规范或审批流程，但通过 Navicat On-Prem Server + 结构同步 + 活动日志组合，可构建轻量、可追溯的团队发布流程。
为什么不能只靠 Navicat 桌面版做变更审计
Navicat 桌面版（如 Navicat Premium、Navicat for MySQL）默认只记录本地操作历史（History 标签页），该记录：
- 仅保存在单台机器上，无法共享或回溯团队行为
- 不包含执行上下文（谁、何时、基于哪个分支/环境、是否经过评审）
- 无法关联 SQL 变更与具体需求或工单编号
- 不拦截高危操作（如
DROP TABLE），也不支持预检或审批钩子
这意味着：哪怕你用桌面版执行了 100 次结构同步，只要没接入协作后端，就等于没有“规范”。
必须启用 Navicat On-Prem Server 才能落地日志规范
Navicat On-Prem Server 是唯一能让变更行为“出账”的组件。它不是可选插件，而是日志和协作的基础设施。启用后：
- 所有连接、查询、结构同步操作会实时写入集中式
活动日志，含操作人、时间、目标库、SQL 内容摘要 - 结构同步任务可被保存为共享项目文件（
.nsync），纳入版本控制或审批前检查 - 团队成员能通过
项目功能共同编辑同一套同步配置，避免“各搞各的” - 管理员可通过
用户管理控制谁能发起同步、谁能执行生产变更
注意：Navicat Cloud 不满足合规要求——日志存储在公有云，且不可审计原始 SQL；On-Prem Server 必须部署在内网，数据完全自主可控。
结构同步必须导出 SQL 脚本并人工审核
Navicat 的结构同步界面虽直观，但直接“执行”按钮是最大风险点。规范流程中，这步必须拆解：
- 比对完成后，务必点击
生成 SQL（而非直接运行），导出.sql文件 - 导出脚本需检查三类内容：
DROP语句是否存在、字段长度缩小时是否有WARNING提示、字符集/排序规则是否一致 - 将
.sql文件提交至 Git，并关联 Jira/Tapd 工单号；由 DBA 或指定同事在 PR 中 Review 后方可合并 - 最终执行时，仍需在 Navicat 中打开该 SQL 文件，手动选择生产连接并运行——杜绝“一键同步到 PROD”
这个过程把 Navicat 从“执行工具”降级为“SQL 预览+执行终端”，把决策权和留痕点交还给流程本身。
活动日志不是摆设，要主动用它做事后归因
活动日志 页面看似简单，但真正起效的前提是：团队习惯性地在每次同步前填写有意义的备注。比如：
- 不要写：“同步订单表”
- 要写：“【ORDER-123】新增 order_status 字段，兼容支付回调幂等逻辑，已测试 dev 环境”
这样当线上出现异常时，你可以：
- 按时间范围筛选
活动日志，快速定位最近一次变更 - 点击日志条目查看完整 SQL，确认是否误删索引或改错默认值
- 结合
执行人字段，直接找到责任人复盘，而不是翻聊天记录猜谁干的
日志本身不会变聪明，但团队对它的使用方式，决定了它能不能成为故障排查的第一响应源。
