Go 的 `database/sql` 标准库不支持单次执行含多个分号分隔的 SQL 语句，需手动拆分并逐条执行（推荐在事务中完成），或使用成熟的数据库迁移工具如 goose 或 rambler。
在 Go 应用初始化阶段（例如安装脚本），常需批量执行 DDL（建表）和 DML（初始数据插入）SQL 脚本。但直接将多语句拼接为一个字符串（如 "CREATE TABLE users(...); INSERT INTO users VALUES (...);"）并调用 db.Exec() 会触发错误：
pq: cannot insert multiple commands into a prepared statement
该限制并非 PostgreSQL 驱动特有，而是 database/sql 包的设计约束：每个 Exec()、Query() 调用仅允许一条 SQL 命令。这是出于安全（防注入）、可预测性及驱动兼容性考虑，并非缺陷。
✅ 推荐方案一：安全拆分 + 显式事务（适用于简单场景）
以下代码演示如何从字符串或文件读取 SQL 内容，按语句分割并在事务中顺序执行：
import (
"database/sql"
"strings"
"io/ioutil"
)
func execSQLScript(db *sql.DB, sqlContent string) error {
tx, err := db.Begin()
if err != nil {
return err
}
defer func() {
if err != nil {
tx.Rollback()
}
}()
// 按分号分割（忽略行尾换行符和空格）
statements := strings.FieldsFunc(sqlContent, func(r rune) bool {
return r == ';' || r == '\n' || r == '\r'
})
for _, stmt := range statements {
stmt = strings.TrimSpace(stmt)
if stmt == "" {
continue
}
if _, err := tx.Exec(stmt); err != nil {
return err
}
}
return tx.Commit()
}
// 使用示例：从字符串加载
err := execSQLScript(db, `
CREATE TABLE users (id SERIAL PRIMARY KEY, name TEXT);
INSERT INTO users (name) VALUES ('Alice'), ('Bob');
`)
// 或从 .sql 文件加载
content, _ := ioutil.ReadFile("schema.sql")
err := execSQLScript(db, string(content))⚠️ 注意事项：
- 避免简单 strings.Split(sql, ";")：可能误切字符串内或注释中的分号（如 'foo;bar' 或 -- comment; ignored）。生产环境建议使用 SQL 解析器（如 sqlparser）或迁移工具。
- 显式事务至关重要：确保 DDL/DML 原子性，失败时自动回滚。
- 空行与注释处理：上述示例仅做基础清理；若脚本含 -- 或 /* */ 注释，需先预处理移除（可借助正则或专用库）。
✅ 推荐方案二：采用专业迁移工具（推荐用于长期维护项目）
对于需要版本控制、回滚、依赖管理的生产环境，应选用成熟迁移框架：
| 工具 | 特点 | 示例 |
|---|---|---|
| goose | 功能完备，支持 Go 逻辑迁移 + SQL 脚本，命令行友好 | goose up, goose create init sql |
| rambler | 轻量级，纯 SQL 迁移，语义化版本控制 | rambler migrate -d ./migrations -u $DSN |
二者均通过约定文件命名（如 20230101120000_init_schema.sql）实现有序执行，并内置事务与错误恢复机制，远优于手写拆分逻辑。
总结
- ❌ 不要尝试绕过 database/sql 多语句限制（如拼接、反射等），违背设计原则且不可移植；
- ✅ 简单脚本：用 strings.FieldsFunc() 安全分割 + sql.Tx 执行，注意清理空白与注释；
- ✅ 中大型项目：立即引入 goose 或 rambler，获得版本化、可审计、可回滚的数据库演进能力；
- ? 进阶需求：如需解析复杂 SQL（含嵌套分号、引号转义），建议集成 sqlparser 或使用 pgx 的 Batch（仅限单连接、非标准 database/sql 兼容）。
选择方案的核心依据是：脚本是否需长期维护？是否涉及团队协作与上线流程？ —— 若答案为“是”，迁移工具不是“更优解”，而是“必选项”。
