Navicat 不支持直接读取 Git 分支中的 SQL 文件，必须先通过 Git 切换到目标分支并确保脚本存在于本地工作区，再在 Navicat 中手动打开执行；执行前需校验编码、替换占位符、确认依赖顺序，并在隔离测试库中验证结果。

Navicat 本身不支持直接读取 Git 分支里的 SQL 文件

这是最常被误解的一点：navicat 是数据库客户端工具，不是版本控制系统客户端。它没有内置 git 集成，不能像 vs code 那样自动拉取 feature/login 分支下的 schema_v2.sql 并执行。你看到的“在 navicat 里打开 git 文件”实际只是手动打开了本地磁盘上某个时刻 checkout 出来的文件。

验证脚本前必须先 checkout 到目标分支并确保文件存在

Git 分支是逻辑概念，脚本内容只在你本地工作区落地后才可被 Navicat 访问。常见错误是直接双击 Navicat 的“打开 SQL 文件”按钮，却忘了自己还在 main 分支，打开的其实是旧版本脚本。

• 用终端或 Git GUI 切换到目标分支：git checkout develop
• 确认脚本路径正确且已更新：git status 查看 migration/202405_add_user_status.sql 是否在暂存区或工作区
• 如果脚本在子模块或远程路径（如 origin/release/v2.1），必须先 git fetch && git checkout -b release-v2.1 origin/release/v2.1，否则 Navicat 打开的是空文件或报错 File not found

在 Navicat 中安全执行脚本的关键操作

直接点击“运行”按钮执行未审核的分支脚本，极易导致生产库结构错乱。Navicat 不校验 SQL 语义，也不区分 DDL/DML 上下文。

openclaw-gitcode-pr-monitor

监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。

下载

• 务必勾选 SQL 编辑器 → 设置 → 运行前提示确认，避免误触执行
• 对含 DROP TABLE 或 ALTER TABLE ... DROP COLUMN 的脚本，先用 EXPLAIN（MySQL）或 pg_prepared_statement（PostgreSQL）模拟执行——但 Navicat 不支持，需切到命令行验证
• 执行前手动替换占位符：比如脚本里写的是 CREATE TABLE ${env}_users，得先替换成 CREATE TABLE dev_users，否则 Navicat 会报语法错误
• 注意字符编码：Git 默认 UTF-8，若 Navicat 连接配置为 gbk，中文注释或字段名会导致 Incorrect string value

真正可靠的验证流程是“Git → 本地文件 → Navicat 连接指定库 → 手动比对”

所谓“验证”，本质是确认该分支脚本在目标库上能成功执行且结果符合预期。Navicat 只承担最后一环的执行和查询职责，中间链路必须人工闭环。

• 建一个临时测试库（如 myapp_dev_feature_x），用 Navicat 新建连接指向它
• 把分支脚本拖进 Navicat SQL 编辑器，检查是否有未提交的本地修改干扰（比如多了一行 DELETE FROM users;）
• 执行后立即查 SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'myapp_dev_feature_x';，对比主干库的表数量
• 关键字段变更必须人工核对：DESCRIBE users; 看 status 字段是否新增、类型是否为 TINYINT(1) 而非 VARCHAR(10)

分支脚本往往依赖前置迁移序号或版本标记，Navicat 不解析这些元信息——漏掉 001_init.sql 就直接跑 002_add_index.sql，大概率报 Table 'users' doesn't exist。