Golang批量插入数据失败处理技巧

本文深入剖析了Golang中批量插入数据时面对部分失败的实战困境，澄清了sql.ErrNoRows与Exec无关的常见误解，强调必须通过类型断言精准捕获PostgreSQL（pq.Error）或MySQL（mysql.MySQLError）驱动级错误，而非依赖脆弱的字符串匹配；对比了ON CONFLICT DO NOTHING与预检+插入等防重策略的适用边界，指出高并发下竞态风险与RETURNING限制，并揭示pgx.Batch虽性能提升3–5倍却带来错误定位与事务控制的新挑战；最终落脚于一个关键洞见：技术方案的选择本质是业务权衡——哪些错误可静默忽略、哪些需实时告警、哪些必须人工介入，代码只是忠实执行这一业务逻辑边界的工具。

Go 批量插入时 Exec 返回 sql.ErrNoRows 是误报吗？

不是误报，但大概率是你没理解它的触发场景——sql.ErrNoRows 只会在使用 QueryRow 或 Scan 类方法且结果集为空时返回，和 Exec 无关。批量插入用 Exec 出错，实际返回的是具体数据库驱动的错误，比如 PostgreSQL 的 pq.Error 或 MySQL 的 mysql.MySQLError。直接判空或只检查 ErrNoRows 会漏掉真实失败。

实操建议：

• 永远用 if err != nil 检查 Exec 结果，不要跳过或仅做 strings.Contains(err.Error(), "duplicate") 这类脆弱判断
• 对 PostgreSQL，类型断言 err.(*pq.Error) 后看 Code 字段（如 "23505" 表示唯一约束冲突）
• MySQL 驱动下，断言 err.(*mysql.MySQLError)，检查 Number（如 1062 是重复键）
• 别依赖错误字符串匹配——字段名、提示语随驱动版本或 locale 变化，不可靠

用 INSERT ... ON CONFLICT DO NOTHING 还是先 SELECT 再 INSERT？

后者在高并发下必然产生竞态，前者才是 PostgreSQL 批量防重的正解。但注意：它只处理“冲突即忽略”，不返回哪些行被跳过，也无法捕获冲突细节。

实操建议：

• 单条插入用 ON CONFLICT DO NOTHING RETURNING id，能通过 Query 获取成功插入的主键；但批量时不支持 RETURNING 与多值 VALUES 直接配合（除非用 UNNEST）
• 真要批量并知道哪些失败，改用 INSERT INTO ... SELECT ... WHERE NOT EXISTS (...) + 临时表或 CTE，但性能下降明显
• 更实用的折中：插入前用 SELECT id FROM table WHERE id = ANY($1) 预检 ID 集合，再用 INSERT ... ON CONFLICT，两次查询换确定性
• MySQL 没有原生 ON CONFLICT，得用 INSERT IGNORE 或 REPLACE INTO，但后者会触发删除+插入，影响自增 ID 和外键级联

pgx.Batch 和原生 sql.DB 批处理性能差多少？

在 PostgreSQL 场景下，pgx.Batch 通常快 3–5 倍，因为它复用连接、避免多次 round-trip、支持二进制协议传输。但代价是错误粒度变粗——整个 batch 失败时，你不知道哪条语句出问题。

实操建议：

• 用 pgx.Batch 时，必须遍历 batchResults 调用 Exec 并检查每个 error，不能只看 batch 整体是否成功
• 如果某条语句失败，pgx 不会自动 rollback 前面成功的语句，需自行控制事务边界（把 batch 放在 Begin() 内）
• sql.DB 的 Prepare + 循环 Exec 更易调试，适合中小批量（
• 别盲目开 10000 条一包——PostgreSQL 默认 max_prepared_statements=100，超限会报 "prepared statement does not exist"

怎么让失败的记录不阻塞后续插入？

核心是放弃“全批原子性”，接受部分成功。但不能简单 try-catch 吞掉错误，否则丢失上下文和监控能力。

实操建议：

• 按业务意义分组，比如按时间分区或用户 ID 哈希，每组 100–500 行，组内失败则整组重试或落库待人工处理
• 用结构体封装每条数据 + 状态字段（status string // "pending", "success", "failed"），失败时更新状态并记录 err.Error()，而非丢弃
• 避免在循环里直接 log.Printf —— 高频插入时 I/O 成瓶颈，改用缓冲日志或异步上报
• 如果失败率持续 > 5%，优先查数据质量（空字段、超长字符串、非法时间戳），而不是堆重试逻辑

真正难的不是语法或 API，是决定哪些错误可忽略、哪些必须告警、哪些要人工介入——这得贴着你的业务约束来划线，代码只是执行者。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。