Na vicat 不支持批量执行多个 .sql 文件，仅能单文件运行且易静默失败；可靠方案是用 psql 命令行配合 shell 循环执行，注意事务隔离、编码统一、跨库拆分及错误中断机制。
Na vicat 里批量执行多个 .sql 文件根本不行
先说一个核心判断：Na vicat 本身并没有“选中多个文件，然后一键执行”这种功能。很多用户以为的“批量执行”，其实是个误会——要么是把“执行一个包含多条语句的文件”当成了批量，要么是借助了外部脚本。实际情况是，Na vicat 一次只能打开并运行一个 .sql 文件。更麻烦的是，当文件里出现 create database、set 命令或者跨库操作时，它很容易静默失败，让你连错在哪都找不到。
真正能批量跑多个 .sql 文件的只有命令行 + psql
那么，可靠的路径在哪里？答案是回归 PostgreSQL 的原生命令行工具：psql。这才是应对 CI/CD、本地初始化或数据迁移等批量场景的正解。关键不在于“怎么点按钮”，而在于“如何组织命令和路径”。
- 首先，
psql支持用-f参数指定单个文件，但它本身不支持像-f *.sql这样的通配符写法。 - 必须借助 shell 循环来实现，比如下面这个经典写法：
for f in ./migrations/*.sql; do psql -U postgres -d mydb -f "$f"; done
- 强烈建议加上
-v ON_ERROR_STOP=1参数，这样任意一条 SQL 出错就会立即中断，避免错误累积。 - 需要警惕的是，如果文件里包含
\c otherdb或CREATE DATABASE这类跨库语句，你得把它们拆分成不同的psql调用来执行——因为psql不会在同一个会话里自动切换数据库。
Na vicat 用户想“假装批量”，只能靠文件合并 + 手动分段
如果非要在 Na vicat 的图形界面里操作，有没有折中办法？有，但本质上只是“模拟”。唯一的可行方案是：把多个 .sql 文件的内容按顺序拼接成一个大文件，然后在文件之间手动插入分隔标记（例如 -- === file: init_users.sql ===），这样出错时好歹能快速定位。但这根本不是真正的批量执行，只是“把多次点击合并成一次点击”而已。
- 合并文件时，务必注意编码统一。尤其是在 Windows 下，用记事本保存的
.sql文件常常带有 BOM 头，这会导致psql报出类似ERROR: unrecognized configuration parameter "SET"这种令人费解的错误。 - Na vicat 会默认使用当前连接的数据库来执行全部语句，它不会自动帮你切换
SET search_path，也不会智能地跳过CREATE SCHEMA IF NOT EXISTS这类语句。 - 特别要注意，包含
COPY命令的文件在 Na vicat 里基本跑不通。因为COPY要求服务端文件路径，而 Na vicat 发送的是客户端协议。这时需要换成\COPY命令——但请注意，这个命令只有psql才支持。
别忽略事务边界和依赖顺序
批量执行时，还有一个更深层的问题容易被忽略：事务边界和文件间的依赖顺序。多个 SQL 文件之间往往环环相扣，比如先建表、再插入数据、最后建立索引。但是，像 psql -f a.sql && psql -f b.sql 这样的连续执行，并不等于“整个流程在一个事务里”。每个文件都是独立的事务，一旦中间某个文件执行失败，前面已经成功提交的文件是无法回滚的。
- 如果需要保证原子性，就必须把所有语句合并进一个文件，并用
BEGIN; ... COMMIT;显式包裹。不过要记住，在 PostgreSQL 中，像CREATE TABLE这样的 DDL 语句通常会隐式提交，即便在事务块中也可能无法回滚。 - Na vicat 的“执行当前查询”按钮对多语句的支持也有限，遇到空行或注释后的换行，执行可能会被意外截断。可以尝试关闭
Tools → Options → SQL Editor中的 “Ignore execution of statements after first error” 选项来改善。 - 话说回来，对于生产环境的批量部署，更专业的做法是使用
pg_restore（对应pg_dump -Fc的备份文件）或者专用的数据库迁移工具，如flyway、liquibase。它们的设计初衷就是用来管理版本和批量变更的，远比手动拼接 SQL 文件来得可靠。
道理就是这些，希望你能避开这些坑。
