批量插入看起来只是把很多数据写进数据库，但真正执行时会遇到超时、锁、事务过大、网络包过大和失败恢复问题。
不要一次写太多
如果一次插入几万条甚至更多数据，很容易出现：
- SQL 过长。
- 网络包过大。
- 事务持续太久。
- 锁占用时间长。
- 回滚成本高。
- 客户端超时。
更稳的做法是拆批写入。
批次大小要可配置
批量插入不要把批次大小写死。
可以从较小批次开始，例如几百或一两千条，再根据表结构、索引数量、数据库压力和网络情况调整。
需要观察：
- 单批耗时。
- 失败率。
- 数据库 CPU。
- 锁等待。
- binlog 增长。
- 主从延迟。
批次大小是工程参数，不是固定答案。
事务边界要清楚
批量写入时，事务可以按批次提交。
这样做的好处是：
- 单次锁时间更短。
- 失败回滚范围更小。
- 更容易断点续跑。
- 日志更容易定位。
如果必须保证全量原子性，就要提前评估事务大小和回滚成本。
不要伪插入
所谓“伪插入”，通常是看起来执行了写入流程，但实际数据没有正确落库，或者失败后没有明确记录。
批量插入要有：
- 输入总数。
- 成功数量。
- 失败数量。
- 当前批次。
- 错误明细。
- 可重试标记。
否则失败后很难知道哪些数据已经写入。
失败恢复
批量写入最好支持断点续跑。
可以记录：
- 批次编号。
- 数据范围。
- 幂等键。
- 已完成状态。
- 失败原因。
- 重试次数。
有唯一键或业务幂等键时，失败恢复会简单很多。
维护建议
数据库批量插入可以按这个清单设计：
- 输入先校验。
- 批次大小可配置。
- 每批独立事务。
- 写审计日志。
- 支持断点续跑。
- 有失败重试和人工补偿入口。
批量插入的目标不是“快点写完”，而是可控、可恢复、可验证。
正文完
