navicat 不支持内置数据库变更审批流程，其“审核”仅限人工生成脚本→检查→执行，无工单、审批链、回写或会签能力；审批必须依赖外部系统集成实现闭环。
navicat 本身不支持内置的数据库变更审批流程，它没有工单系统、角色审批链、操作回写或三方会签能力。你不能靠点几下“开启审批”就让生产ddl经过dba+安全+合规联合确认——这是工具定位决定的硬限制。
Navicat 的“审核”只能靠人肉+外部配合
所谓“审核”，在 Navicat 中实际是指：把变更动作从“直接执行”变成“先生成脚本→人工检查→再执行”。这依赖操作者自觉，不构成流程闭环。
- 结构同步时勾选
Generate SQL File而非Run Synchronously，导出sync_diff.sql后交由他人审阅 - 新建查询窗口中写完
ALTER TABLE不点执行，而是复制语句粘贴到企业微信/钉钉/飞书里发起文字评审 - 用
Export SQL File功能导出整个库的 DDL 快照，和 Git 提交记录绑定，作为事后审计依据 - 所有审查结论、修改意见、签字确认都得脱离 Navicat，在 Jira/Tapd/自建审批系统里完成
为什么不能依赖 Navicat 自带权限做审批
Navicat 连接账号的权限控制（如只给 SELECT, ALTER）只是数据库层访问控制，不是审批行为。它解决不了“谁批准了这次变更”这个核心问题。
-
GRANT ALTER ON prod_schema.orders TO 'navicat_prod'只表示这个账号能改表，不代表每次ALTER都被授权过 - Navicat 日志只记
User A executed ALTER TABLE orders ADD COLUMN status TINYINT，不关联工单号、审批人、过期时间 - 没有拒绝机制：即使 DBA 在群里说“暂缓上线”，只要账号有权限，开发仍可在 Navicat 里一键执行
- 审计时无法回答：“这条语句是哪份工单触发的？谁复核的？是否超时未执行？”
真要落地审批，必须绕开 Navicat 做集成
如果你团队已有审批平台（如自研系统、Jira Service Management、钉钉宜搭），可以把 Navicat 当作“SQL 脚本生成器 + 执行终端”，而不是审批入口。
- 开发用 Navicat 的
Structure Sync生成变更脚本 → 上传至审批系统附件 → 触发审批流 - 审批通过后，系统自动把脚本推送到指定环境的执行队列 → 由运维用 Navicat 或命令行执行（或调用 API）
- 执行结果（成功/失败/耗时/影响行数）需由脚本捕获并回调写入审批单，否则闭环就断了
- 关键点在于：审批系统必须能识别 Navicat 导出的 SQL 文件结构（比如解析出涉及的表名、操作类型），否则光传个文件等于没审
真正卡住多数团队的，不是不会点 Navicat 的按钮，而是没意识到：审批流程的起点不在客户端界面，而在谁有权发起、谁必须参与、审批状态如何影响后续执行这三个环节。Navicat 只能贡献第一环的“发起”动作，剩下两环它既不感知，也不响应。
