Na vicat 不支持直接读取 Git 分支中的 SQL 文件，必须先通过 Git 切换到目标分支并确保脚本存在于本地工作区，再在 Na vicat 中手动打开执行；执行前需校验编码、替换占位符、确认依赖顺序，并在隔离测试库中验证结果。
Na vicat 本身不支持直接读取 Git 分支里的 SQL 文件
有一点常常被误解：Na vicat 是数据库客户端工具，并非版本控制系统客户端。它没有内置 Git 集成，无法像 VS Code 那样自动拉取 feature/login 分支下的 schema_v2.sql 并执行。所谓的“在 Na vicat 里打开 Git 文件”，实际上只是手动打开了本地磁盘上某个时刻检出的文件。
验证脚本前必须先 checkout 到目标分支并确保文件存在
Git 分支是逻辑概念，脚本内容只在你本地工作区落地后才可被 Na vicat 访问。常见错误是直接双击 Na vicat 的“打开 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，否则 Na vicat 打开的是空文件或报错File not found
在 Na vicat 中安全执行脚本的关键操作
直接点击“运行”按钮执行未审核的分支脚本，极易导致生产库结构错乱。Na vicat 不校验 SQL 语义，也不区分 DDL/DML 上下文。
- 务必勾选
SQL 编辑器 → 设置 → 运行前提示确认，避免误触执行 - 对含
DROP TABLE或ALTER TABLE ... DROP COLUMN的脚本，先用EXPLAIN（MySQL）或pg_prepared_statement（PostgreSQL）模拟执行——但 Na vicat 不支持，需切到命令行验证 - 执行前手动替换占位符：比如脚本里写的是
CREATE TABLE ${env}_users，得先替换成CREATE TABLE dev_users，否则 Na vicat 会报语法错误 - 注意字符编码：Git 默认 UTF-8，若 Na vicat 连接配置为
gbk，中文注释或字段名会导致Incorrect string value
真正可靠的验证流程是“Git → 本地文件 → Na vicat 连接指定库 → 手动比对”
所谓“验证”，本质是确认该分支脚本在目标库上能成功执行且结果符合预期。Na vicat 只承担最后一环的执行和查询职责，中间链路必须人工闭环。
- 建一个临时测试库（如
myapp_dev_feature_x），用 Na vicat 新建连接指向它 - 把分支脚本拖进 Na vicat SQL 编辑器，检查是否有未提交的本地修改干扰（比如多了一行
DELETE FROM users;） - 执行后立即查
SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'myapp_dev_feature_x';，对比主干库的表数量 - 关键字段变更必须人工核对：
DESCRIBE users;看status字段是否新增、类型是否为TINYINT(1)而非VARCHAR(10)
分支脚本往往依赖前置迁移序号或版本标记，Na vicat 不解析这些元信息——漏掉 001_init.sql 就直接跑 002_add_index.sql，大概率报 Table 'users' doesn't exist。
