批量插入更快的本质是减少网络往返和事务开销；单次批量宜控制在100–500行，需妥善处理边界、错误重试及orm隐藏成本。
为什么批量插入比逐条执行快得多
本质是减少网络往返和事务开销。INSERT INTO users VALUES (...) 每执行一次，就要走一次 TCP 往返 + 日志刷盘 + 索引更新。100 条数据逐条插，可能触发 100 次磁盘 I/O；合并成一条 INSERT INTO users VALUES (...), (...), (...)，通常只要 1–2 次。
但要注意：不是越大批量越好。MySQL 默认 max_allowed_packet 通常是 4MB，PostgreSQL 有 work_mem 和协议限制，超出会直接报错 ERROR: 22001: string data, right truncation 或连接中断。
实操建议：
- 单次批量大小控制在 100–500 行较稳妥（具体看单行数据长度）
- 用
len(data) % batchSize == 0做切片边界判断，别用for i := 0; i ，容易越界 - SQLite 用户注意：
PRAGMA journal_mode = WAL能显著提升批量写入吞吐，否则默认 DELETE 模式下每批仍会锁表
Go 标准库 database/sql 怎么安全做批量插入
标准库不原生支持多值 INSERT 参数绑定，硬拼 SQL 字符串易被注入，也难处理 NULL、时间、字节等类型。正确姿势是动态生成占位符，再展开参数列表。
立即学习“go语言免费学习笔记（深入）”；
常见错误：直接写 INSERT INTO t (a,b) VALUES (?, ?), (?, ?) 却只传 2 个参数，导致 sql: expected 2 arguments, got 4。
实操建议：
- 用
strings.Repeat("(?, ?),", n-1) + "(?, ?)"拼占位符串，别手写 - 参数用
append([]interface{}{}, args...)展开，确保类型一致（int64别混int） - 务必用
tx, err := db.Begin()包裹整批操作，失败时调用tx.Rollback()，别依赖单条语句的自动回滚 - PostgreSQL 用户可考虑
pgx驱动的Batch接口，它底层复用连接、自动分片，比纯database/sql更省心
什么时候该用 channel + worker 模式做异步批处理
当写入来源不可控（比如 HTTP 请求、消息队列）、吞吐波动大、或需要削峰填谷时，硬同步批量反而会卡住上游。这时用 chan []Item 接收数据，后台 goroutine 定期收拢、合并、落库更合理。
典型翻车点：channel 不设缓冲或缓冲太小，导致生产者阻塞；或 worker 没做 recover，panic 后整个批处理协程静默退出。
实操建议：
- channel 缓冲设为
batchSize * 2，避免瞬间洪峰打爆内存 - worker 内用
time.AfterFunc或time.Ticker触发 flush，别单纯靠len(batch) >= size—— 最后一批可能永远不来 - 每个 batch 处理完必须调用
db.Exec并检查err != nil，失败日志里至少记下len(batch)和首条 ID，方便排查是数据问题还是 DB 临时抖动 - 别在 worker 里直接
log.Fatal，用panic+recover捕获并重试 1 次，之后丢弃或发告警
ORM（如 GORM）批量操作的隐藏成本
GORM 的 CreateInBatches 看似省事，但它默认对每批数据都调用 BeforeCreate 钩子、做 struct tag 解析、字段零值过滤。10 万条数据分 200 批，就额外执行 200 次反射和钩子函数，性能可能反不如裸 SQL。
更隐蔽的问题：GORM 会把 time.Time 自动转成带微秒的字符串，而 MySQL 5.6 默认只存到秒，导致批量插入时部分字段被截断为 0000-00-00 00:00:00，且不报错。
实操建议：
- 高吞吐场景绕过 ORM，用
db.Exec直连，哪怕多写几行 SQL 拼接逻辑 - 必须用 GORM 时，关掉无用钩子：
db.Session(&gorm.Session{SkipHooks: true}) - 显式指定时间精度：
CreatedAt time.Time `gorm:"precision:0"`，匹配 MySQL 实际字段定义 - 用
db.Debug().CreateInBatches(...)抓出真实生成的 SQL，确认是否有多余的WHERE或ORDER BY
批量处理真正的难点不在“怎么凑够 100 条”，而在于边界情况：最后不满一批怎么 flush、中间某条数据格式非法怎么跳过、DB 连接断了重试几次才放弃。这些逻辑一旦漏掉，线上就变成定时静默丢数据。
