Java JDBC 批量提交 怎样处理

JDBC 批量提交要把两个边界分开：executeBatch 负责执行已加入批次的语句，commit 负责完成事务。想让一组导入数据共同成功或失败，应在独占连接上关闭自动提交，分块执行批次，全部完成后再提交；失败时回滚，而不是把“批次执行完”当成“数据已持久提交”。

官方 API 入口：https://docs.oracle.com/en/java/javase/26/docs/api/java.sql/java/sql/Connection.html。本文沿用常规 JDBC API，不涉及框架托管事务，也不声称下面的示例已经连接数据库或完成性能测试。

导入分成十批，不一定要提交十次

假设一个标签导入任务，需要写入一组编号与名称，要求本次数据共同完成。为了控制驱动积累的参数数量，可以每 200 条执行一次批次，但仍把所有批次放在同一个事务内。200 只是示例参数，和业务的原子性要求没有必然关系。

旧写法的问题通常不是缺少 addBatch，而是没有明确谁管理连接和事务。有的代码保持自动提交，有的代码每执行一块就提交，还有的代码在服务层异常后直接重跑整组。这些方案的失败含义不同，不能都叫“批量提交”而忽略区别。

本文给出的规则是一种应用选择：分块执行，但只在最后提交一次。它不是 JDBC 新版本修改了语义，也不表示所有大任务都适合一个长事务。

先确认连接归属和数据库前提

示例假定已有事务型表 import_label，包含唯一的 item_id 与 label_text 两列；列类型与长度由目标数据库建表规范确定。输入数据已经完成权限及业务格式检查，DataSource 已按目标驱动配置。本文不提供通用建表脚本，避免把不同数据库的 DDL 和事务行为混在一起。

连接必须由本次方法独占，不能传入 Spring、JTA 或外层业务已经管理的事务。若已有事务管理器，应由它决定提交和回滚，底层方法只处理批次执行，不能在内部偷偷 commit。

还要核对驱动支持批处理、表具备所需事务语义，以及触发器或外部副作用是否也处于业务可恢复范围。数据库回滚不负责撤回已经发出的网络通知。

分块执行，把提交留到最后

下面是可放入独立类中的原创方法。它不保留整批 SQL 字符串，而是绑定参数；每批执行后清理批次，尾部不足一批的数据也会执行。该方法没有自动重试。

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.SQLException;
import java.util.List;
import javax.sql.DataSource;

public final class LabelBatchWriter {
    public record Row(long itemId, String label) {}

    public static void write(DataSource source, List rows, int batchSize)
            throws SQLException {
        // 入参先检查，避免进入事务后才发现配置错误
        if (source == null || rows == null || batchSize  0) {
                        statement.executeBatch();
                        statement.clearBatch();
                    }
                }

                commitAttempted = true;
                connection.commit();
            } catch (SQLException | RuntimeException | Error failure) {
                // 回滚属于尽力处理；保留失败线索，不能覆盖原始异常
                try {
                    connection.rollback();
                } catch (SQLException rollbackFailure) {
                    failure.addSuppressed(rollbackFailure);
                }
                if (commitAttempted) {
                    // 提交期间失败时不能宣称数据库一定没有提交
                    throw new SQLException("commit outcome requires reconciliation", failure);
                }
                throw failure;
            }
            // 不在失败路径切回自动提交；连接交还由DataSource规范清理
        }
    }
}

调用方传入已配置的 DataSource 和 Row 列表，例如选择 200 作为起始批大小。示例不包含账户密码，也没有读取真实业务输入。正常返回表示这次 commit 已返回成功且资源关闭没有报错；但方法抛异常不必然表示数据未提交，尤其需要区分提交与后续连接关闭阶段。

连接池必须能在归还时正确清理事务和状态，对失效连接按驱动及池的规则淘汰。不要把这段代码理解成可以忽略连接池行为的完整连接治理方案。若 rollback 失败，更不能手动切回 autoCommit=true 后继续复用同一个连接。

BatchUpdateException 的计数不是提交证明

批更新失败时，驱动可能在错误处停止，也可能继续处理剩余命令。BatchUpdateException 的更新计数需要按驱动行为解释，不能只看数组长度就断定哪些数据已经永久写入。

Statement 定义了 SUCCESS_NO_INFO，表示语句执行成功但没有具体影响行数；EXECUTE_FAILED 表示批中执行失败。它们不是普通行数，不能简单把整个数组相加，也不该把所有负数都判为同一种错误。

本例采用任意执行异常即尝试回滚整组的策略，因此不根据局部更新计数接着提交剩余数据。若业务希望跳过坏行，应另行设计任务结果与事务边界，不能只在 catch 中打印异常后继续 commit。

提交时断线，为什么不能直接重跑？

executeBatch 在事务中执行成功，与 commit 期间客户端收到成功确认是两件事。提交阶段连接中断时，数据库可能已经完成提交，而客户端没有收到结果；此时再次 rollback 的调用也不能证明原提交没有发生。

建议为导入任务设计可追踪的业务请求标识、唯一约束和对账状态，并在结果未知时进入核对流程。唯一键只是防重复的一部分，不能自动决定重复记录内容不同、局部冲突或任务状态该怎样处理。

连接关闭报错也要结合提交阶段记录判断。不能把任何 SQLException 都当作“整组已回滚”，更不能把所有异常都接入无条件自动重试。日志应保留任务标识、批次位置、异常分类和回滚异常，不应打印完整敏感输入或数据库凭据。

什么时候才应该每块提交？

如果任务规模使一个长事务带来不可接受的锁持有、日志或回滚压力，可以考虑分块提交，但这会改变业务语义：前面已提交的块不会因为后面失败而整体撤销。需要记录完成位置，并让恢复逻辑知道哪些块已经确认，而不是把它称为同一个原子事务。

executeBatch 是否会自动完成事务？不能把它当作显式 commit 的替代。批次越大是否越快？需要用目标驱动、数据规模和数据库负载测量，没有通用最佳值。能否在事务管理框架中照抄整个方法？不应照抄连接生命周期，应遵守框架的事务归属。

采用前先确定原子性要求，再选批大小；随后明确异常路径、连接清理和对账方式。只有这些边界都清楚，批量执行才是可维护的数据写入方式，而不只是把循环里的 SQL 换成另一个方法。

参考：JDBC Connection 事务接口、Statement 批处理与计数、BatchUpdateException 驱动差异。