go 的 database/sql 不支持真正的 bulk insert，仅能通过多值 insert 实现伪批量；pgx 的 copyfrom 可实现 postgresql 原生高效 bulk，mysql 则需控制单次行数并调优连接与事务。
Go 的 database/sql 本身不支持真正的 bulk insert
别被“bulk”这个词带偏了——database/sql 标准库没有类似 PostgreSQL 的 COPY 或 MySQL 的 LOAD DATA INFILE 这种底层批量导入能力。它所有写操作都走 Prepare + Exec 或 Query，本质是单条或多条 SQL 语句的拼接执行。
这意味着：你写的 INSERT INTO t VALUES (?, ?), (?, ?), (?, ?) 算“伪 bulk”，上限受数据库单语句长度、参数个数、内存缓冲限制；而真正高效的 bulk（如 pgx 的 CopyFrom）绕过了 SQL 解析层。
- MySQL 官方驱动（
go-sql-driver/mysql）最多支持约 65535 个占位符，但实际建议单次不超过 1000 行，否则易触发Packet too large - PostgreSQL 的
lib/pq对多值INSERT更宽容，但超 1 万行后性能增长趋缓，且事务日志膨胀快 - SQLite 的
sqlite3驱动在批量时需手动开启PRAGMA journal_mode = WAL和PRAGMA synchronous = OFF才不拖垮速度
用 pgx 的 CopyFrom 实现真 bulk（PostgreSQL 场景）
如果你用的是 PostgreSQL，pgx 是目前 Go 生态中唯一稳定提供原生 COPY 协议支持的驱动。它不拼 SQL，直接流式传输二进制数据，吞吐量通常是普通 INSERT 的 5–20 倍。
关键点不是“怎么写”，而是“怎么准备数据”和“怎么配连接”：
立即学习“go语言免费学习笔记（深入）”；
- 必须使用
pgxpool或pgx.Conn，不能用*sql.DB包装器，否则CopyFrom不可用 - 目标表字段顺序、类型必须与你传入的
[]interface{}或结构体严格对齐，错一位就报column "xxx" is of type xxx but expression is of type xxx - NULL 值必须用
nil，不能传0或空字符串，否则会插入默认值甚至报错 - 示例片段：
_, err := conn.CopyFrom(ctx, pgx.Identifier{"users"}, []string{"id", "name", "email"}, pgx.CopyFromRows(data))其中data是[][]interface{}，每行一个 slice
MySQL 怎么逼近 bulk 效果（不用 LOAD DATA）
MySQL 官方驱动不支持 LOAD DATA 协议（需要文件路径权限），所以退而求其次：靠“够大但不过载”的多值 INSERT + 连接调优。
核心不是拼得越多越好，而是平衡网络往返、单语句解析开销和事务一致性：
- 单次
INSERT控制在 500–2000 行之间（视平均行宽而定），太小浪费 round-trip，太大触发max_allowed_packet - 务必用
tx, _ := db.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelReadUncommitted})包裹批次，避免每条都开事务 - 连接串加上
multiStatements=true&parseTime=true（如果用 time.Time），否则时间字段可能解析失败 - 错误处理要细粒度：不要只看
Exec返回 err，还要检查sql.Result.RowsAffected()是否匹配预期，防止部分插入成功却误判失败
通用陷阱：事务、上下文、类型转换
批量写入最容易翻车的地方，往往不在 SQL 本身，而在周边控制逻辑。
-
context.WithTimeout时间设太短：插 10 万行可能耗时数秒，但默认 HTTP 请求 context 只有 5 秒，导致中途 cancel，连接复用失效甚至留下脏事务 - struct 转
[]interface{}时用反射或unsafe强转，结果某字段是*int却传了int，运行时报cannot convert int to driver.Valuer - 没关自动提交又没显式
Commit：尤其用sql.DB直接Exec多条，看似成功，其实每条都是独立事务，性能差还难回滚 - 批量前忘了
TRUNCATE或DELETE清理，但没加 WHERE，误删全表——这不属于 Go 技术问题，但发生在批量场景下频率极高
真正卡住人的，往往是这些和“bulk insert”字面无关、却决定成败的细节。
