应使用Exec替代Query执行单条INSERT以避免结果集解析开销，并复用预编译语句；批量插入优先采用多值INSERT语法，控制单条不超过1000行；配合合理事务粒度（每1000–5000行提交）、连接池调优及原生驱动（如pgx）可显著提升吞吐。
用 Exec 替代多次 Query 执行单条 INSERT
Go 的 database/sql 包中，Query 会返回 *Rows，即使你只插入一条数据也触发结果集解析开销；而批量写入通常不需要返回结果。直接用 Exec 更轻量，且能复用预编译语句。
- 每次
Query都隐式调用Prepare+Query，而Exec可显式复用*Stmt - 对 PostgreSQL/MySQL，预编译语句（
Prepare）在连接池内可被复用，但需注意驱动是否开启（如pgx默认启用，lib/pq需手动控制） - 示例：用
stmt.Exec(args...)替代db.Query("INSERT...", args...)
拼接多值 INSERT 语句（INSERT INTO ... VALUES (),(),()）
这是提升吞吐最直接的手段，但要注意数据库单语句长度和参数上限。MySQL 默认 max_allowed_packet=4MB，PostgreSQL 默认 work_mem 影响解析，实际建议单条不超过 1000 行。
- 不要手拼 SQL 字符串——用
strings.Repeat构造占位符，再用fmt.Sprintf拼接语句模板 - 例如：
INSERT INTO users(name,age) VALUES %s+strings.Repeat("(?,?),", n-1) + "(?,?)" - 传参时把所有值 flatten 成一个
[]interface{}，避免反射开销 - SQLite 不支持多值 INSERT（v3.7.11+ 支持，但 Go 驱动
mattn/go-sqlite3兼容性需验证）
用 sql.Tx 包裹批量操作，但别滥用大事务
不加事务时，每条语句都是自动提交，IO 和日志刷盘频率极高；加事务能合并 WAL 写入、减少锁竞争。但事务过大可能阻塞 vacuum（PostgreSQL）、撑爆 undo log（MySQL InnoDB），甚至触发超时回滚。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 推荐每 1000–5000 行提交一次，具体看单行大小和数据库负载
- 用
tx, err := db.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelReadCommitted})显式控制隔离级别，避免默认串行化开销 - 务必用
defer tx.Rollback()+if err == nil { tx.Commit() }模式，防止 panic 导致事务悬挂 - MySQL 中，大事务还会导致主从延迟加剧，需监控
Seconds_Behind_Master
换用原生驱动或连接池优化（如 pgx / sql.DB.SetMaxOpenConns）
标准 database/sql 是接口层，性能瓶颈常卡在驱动实现和连接调度上。比如 lib/pq 是纯 Go 实现但较旧，pgx 支持二进制协议和批量操作原语（pgx.Batch），MySQL 场景可考虑 go-sql-driver/mysql 的 multiStatements=true（慎用，有注入风险）。
立即学习“go语言免费学习笔记（深入）”；
-
sql.DB.SetMaxOpenConns(20)和SetMaxIdleConns(10)必须调，否则默认无限开连接，容易打满 DB 连接数 -
pgx的Batch可自动分片、并发执行，比手写循环快 3–5 倍（实测 10w 行插入） - 避免在循环里反复调
db.Prepare，应提至循环外，或用db.Stmt缓存 - 注意
context.WithTimeout传给ExecContext，防止某批卡死拖垮整个流程
批量操作真正的瓶颈往往不在 Go 代码本身，而在事务粒度、网络往返次数和驱动协议支持程度。先测单条 vs 多值 vs Batch 的耗时差异，再决定是否引入新依赖；很多项目卡在没关连接池或用了 Query 而不是 Exec，这些细节比算法优化更关键。
