多线程批量插入数据库：@Transactional失效与手动事务实战

拿一个我经手过的真实需求来说：一张Excel表格，50万行业务数据，要导进MySQL里。最早我用for循环一条一条插入，跑了足足四十多分钟，业务方当场坐不住了。后来改成多线程批量插入，再把事务处理从@Transactional换成手动事务方案，整体时间直接压缩到几十秒，数据也能按批次稳定落库。这个过程中踩的坑，尤其是@Transactional在多线程下失效的问题，几乎每个做Java后端的同学都会遇到。

这篇文章就把这套多线程批量插入数据库的完整思路拆开讲清楚：先说为什么需要它，再彻底解释@Transactional为什么在子线程里“不听话”，然后给出手动事务的完整落地代码，最后附上连接池、线程池、MySQL批量写入的调优参数和常见问题排查清单。适合刚接触并发编程的初级开发，也适合写过批量导入但没深究过事务原理的中高级工程师。

1. 多线程批量插入：从业务痛点倒推技术方案

1.1 先说清楚什么场景需要多线程插入

很多人一开始对“多线程批量插入”有误解，以为只是为了炫技。实际上它解决的是一类非常朴素的业务问题：单条插入太慢，慢到无法接受。

单条INSERT在MySQL里慢在哪，拆解开其实就三块：网络往返、事务提交开销、SQL解析执行。每一条都要走一次客户端到服务端的完整往返，哪怕连接池复用连接，这个RTT也省不掉。而且如果每条都单独提交，MySQL要刷一次binlog和redo log，事务提交的成本全部打在单条数据上。数据量到几万条以后，这个性能损失会放大得非常明显。

批量插入的优化思路也很直接：把多条数据的INSERT拼接成一条多值SQL，或者用JDBC的addBatch一次性提交，让原本需要往返N次的请求变成发送一次请求，SQL执行引擎在内部循环写入。单靠这一步，插入性能就能提升10倍以上。

当批量插入还不够快时，第二步才是拆线程并行。但要注意，多线程不是银弹，它是在“单条插入已优化为批量插入”的基线上再做的加速。如果连批量都没做就上多线程，那等于一边加并发一边放大单条插入的开销，效果会非常差。

1.2 串行改并行的两个关键动作

把一段串行插入逻辑改成并行，看起来就是把for循环换成线程池，但实际操作中核心是两步：先分批，再分片提交。

分批指的是每次提交的数据量要控制在合理范围。我常用的经验值是500到2000条一批，具体取决于单条记录字段多少和大小。字段多、单条记录文本长，就往下调；字段少、数据紧凑，可以往上走。这一步是为了避免SQL语句过长触碰max_allowed_packet限制，也让单批事务的执行时间可控。

分片指的是把总数据集划分成若干互不重叠的子集，交给不同线程处理。最简单的方式是直接用Guava的Lists.partition按固定大小切分，或者按主键取模、按ID区间分段。分片设计直接决定了并行任务之间会不会出现重复写入或漏写，划分原则就一条：每个数据块有且只有一个线程负责，线程之间没有交集。

只要这两个动作做对，插入性能基本就能形成“单线程批量”乘以“线程数”的量级提升。实测一个5万行的导入任务，单线程批量插入大约需要几分钟，改成4个线程并行后，三分半的任务能压到四十秒左右，再配合后续提到的MySQL参数，可以进一步压缩到十几秒。

1.3 事务粒度的权衡：大事务还是批量小事务

串行插入的时候，很多人习惯在最外层方法上直接加@Transactional，想着“所有数据要么都成功，要么都不成功”，这种思路确实符合直觉。但一旦上了多线程，这个“大事务”思路就要立刻抛弃。

问题出在事务的粒度上。一个事务如果覆盖了全部50万条数据，意味着要持有一堆行锁或者间隙锁很长时间，在此期间任何其他事务对相关表的DML都会被阻塞。更糟的是，多线程并行时如果也套用这个大事务思路，每个线程拿到的连接都归入同一个事务里，那这个事务本质上已经把并发拖回了串行——因为多个线程必须在同一个事务下协同工作，协调成本极高，而且连接之间的事务隔离让这件事几乎无法实现。

所以工程上最终几乎都选择“批量小事务”：每个分片任务自己开一个事务，每批500条数据一个事务，执行完就提交，出错就只回滚这一批。这样做有几大好处：锁持有时间短，冲突概率小；失败影响面可控，最多回滚一批；配合失败重试，整个任务最终可以把数据全部写入成功。

后面讲到手动事务，本质就是把“大事务”的幻想打破，改成若干个短小精悍的分片事务。

2. @Transactional在多线程环境为什么失效

2.1 一段看似正确但注定出问题的代码

先看一段我见过很多次的写法，它的意图是“用多线程加速插入，用@Transactional保证整体原子性”：

java复制@Transactional
public void batchInsert(List<UserInfo> list) {
    List<List<UserInfo>> partition = Lists.partition(list, 1000);
    ExecutorService executor = Executors.newFixedThreadPool(8);
    for (List<UserInfo> batch : partition) {
        executor.execute(() -> userMapper.batchInsert(batch));
    }
    executor.shutdown();
}

这段代码实际跑起来会出现几种情况：要么报连接超时异常，要么某些线程插入的数据部分成功部分丢失，要么无论如何回滚都无法把所有数据回滚掉。原因非常简单：外层方法上的@Transactional只在主线程中生效，子线程里执行的插入操作根本不在这个事务范围内。

这里更迷惑人的是，看起来代码确实是“同一个方法里调用了一个被Spring管理的Mapper”，直觉上以为事务应该全局笼罩着所有数据。但Spring的事务设计和我们直觉理解的“全局事务”完全不同，它的事务边界从来都是跟着线程走的。

2.2 底层原理：Spring事务是怎么绑定线程的

Spring的@Transactional底层依赖AOP拦截器+事务同步管理器。拦截器在方法执行前获取数据库连接，调用connection.setAutoCommit(false)，然后通过DataSourceUtils把当前连接绑定到一个ThreadLocal上。后续同一个线程里执行的SQL操作，都会从这个ThreadLocal里取出同一个Connection，从而处于同一个事务内。

问题就出在ThreadLocal上。线程是一个个独立的执行上下文，主线程里绑定的Connection，子线程根本读不到。子线程自己去操作数据库时，只能从连接池里拿一条全新的连接，这条新连接默认处于自动提交模式，所以每一条插入都会立即提交，压根不受外层事务控制的约束。

用生活里的例子类比：你可以把Spring事务想象成一张“工地出入证”，Spring把这个证塞进了主线程的裤子口袋里。主线程干活时能掏出证来进出工地，一证一人一操作，管理得清清楚楚。但子线程是另一个人，它穿的是自己的裤子，口袋里空空如也，自然拿不到主线程那张出入证。它只能自己去前台重新办一张临时证，临时证自己管自己，和主线程那张证毫无关系。

所以结论很直接：Spring事务是基于线程的，不是基于方法的。只要事务跨越了线程边界，父线程的事务就管不到子线程，子线程里也不会自动继承父线程的事务上下文。

2.3 失效的另外几种常见姿势

除了直接往ExecutorService里丢任务，还有几种写法同样会踩到@Transactional失效的坑：

使用parallelStream()并行流。比如list.parallelStream().forEach(item -> mapper.insert(item))，默认使用ForkJoinPool公共线程池，这些工作线程同样没有主线程的事务上下文。外层方法即使标了@Transactional，也只覆盖主线程那段微不足道的逻辑，子任务不参与事务。

使用@Async注解实现异步。我把一个插入方法标注@Async，然后从带有@Transactional的方法里调用它，看起来好像子方法应该归入父方法事务。实际上@Async本身就是把方法丢进另一个线程执行，子线程拿不到父线程的事务连接，每个异步任务各行其是。

更隐蔽的一个坑是同类内部调用。比如Service类中的方法A标了@Transactional，方法B内部直接this.a()调用它。由于Spring AOP代理只拦截外部Bean调用，类内部this调用不会经过代理，事务注解直接失效。这种场景和多线程无关，但在事务失效排查表里出现的频率特别高，值得并列提一嘴。

2.4 外层大事务会引发连接池和锁问题

多线程插入时如果坚持给外层方法加@Transactional，后果不只是事务不生效，还会带来更严重的副作用——连接池被耗尽。

想象一下这个流程：外层方法拦截器先开启事务，从连接池拿走了第一条连接，并且要求主线程持有这条连接直到方法结束。主线程接着启动8个子线程，每个子线程去插入数据时，连接池里又付出8条连接。如果外层方法执行完之前这些子线程不结束，那连接池里至少9条连接处于被占用状态。

如果项目的HikariCP连接池最大连接数是10，这9条连接已经把池子几乎占满。此时任何一个新的连接请求，哪怕是健康检查、元数据查询、其他接口的数据库访问，都会进入等待队列。子线程如果内部还有分批提交逻辑，需要连续获取多条连接，极易触发Connection is not available, request timed out超时。

大事务本身还会持有大量行锁。多个子线程同时更新范围相近的数据时，互相等待锁释放，很快就会出现死锁，MySQL直接抛Deadlock found when trying to get lock。外层事务包得越大，这个锁冲突窗口就越长，问题就越严重。

3. 手动事务解决方案：自己掌控事务边界

3.1 方案选型：TransactionTemplate还是DataSourceTransactionManager

既然@Transactional在多线程下靠不住，最直接的办法就是把事务管理权从注解手里拿出来，改成编程式事务。Spring提供了两种主流做法，它们的底层都是同一个东西，只是封装程度不同。

我一般把选择原则压缩成一句话：能用TransactionTemplate就用TransactionTemplate，只有当需要极其精细的挂起、恢复、传播行为控制时才考虑直接操作DataSourceTransactionManager。

两种方案的具体对比，拿表格看更清晰：

另外强调一点，不要直接用Connection.setAutoCommit(false)这种手工JDBC事务。绕开Spring事务同步管理之后，操作数据库的Mapper可能走的是另一条连接，事务根本包不住预期范围内的操作；而且手动管理Connection极易忘记关闭导致连接泄漏。Spring环境下，正确的手动事务就是编程式事务管理器或TransactionTemplate。

3.2 用TransactionTemplate替代@Transactional的完整示例

TransactionTemplate的使用思路很清晰：把每一批数据的插入动作放进一个回调方法，模板负责在这个回调执行前开启事务，回调正常结束就提交，回调抛异常就回滚。

先注入必要组件：

java复制@Service
public class BatchImportService {

    @Autowired
    private UserMapper userMapper;

    @Autowired
    private TransactionTemplate transactionTemplate;

    private static final int BATCH_SIZE = 500;

    public void parallelBatchInsert(List<UserInfo> allData) {
        // 数据切分
        List<List<UserInfo>> batches = partition(allData, BATCH_SIZE);
        // 线程池交给单独的配置类管理，这里直接用固定线程池演示
        ExecutorService executor = Executors.newFixedThreadPool(4);
        // 统计结果
        AtomicInteger successCount = new AtomicInteger();
        AtomicInteger failCount = new AtomicInteger();
        List<Throwable> errors = Collections.synchronizedList(new ArrayList<>());
        CountDownLatch latch = new CountDownLatch(batches.size());

        for (List<UserInfo> batch : batches) {
            executor.execute(() -> {
                try {
                    // 每个分片内部使用独立的小事务
                    transactionTemplate.executeWithoutResult(status -> {
                        userMapper.batchInsert(batch);
                    });
                    successCount.addAndGet(batch.size());
                } catch (Exception e) {
                    failCount.addAndGet(batch.size());
                    errors.add(e);
                    log.error("批次插入失败，影响行数: {}", batch.size(), e);
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await();
        executor.shutdown();

        log.info("导入完成，成功: {}, 失败: {}", successCount.get(), failCount.get());
        if (!errors.isEmpty()) {
            // 可抛出业务异常或入库失败明细，便于后续补偿
        }
    }
}

这段代码比单纯的@Transactional多做的事情，是把“事务边界”从一个巨大的方法级别缩小到了每一批数据上。任何一个批次插入失败，只会回滚自己的500条，不会影响其他线程已经提交成功的数据。successCount和failCount则提供了清晰的成功失败统计，方便业务做后续对账。

3.3 用DataSourceTransactionManager手动控制事务

如果你确实需要拿到TransactionStatus对象去做更复杂的控制，比如事务挂起、恢复，或者在一个事务里穿插若干条件判断后再决定是否提交，那就要直接用DataSourceTransactionManager。

java复制@Service
public class ManualTransactionService {

    @Autowired
    private UserMapper userMapper;

    @Autowired
    private PlatformTransactionManager transactionManager;

    public void insertWithManualTx(List<UserInfo> batch) {
        DefaultTransactionDefinition definition = new DefaultTransactionDefinition();
        definition.setIsolationLevel(TransactionDefinition.ISOLATION_DEFAULT);
        definition.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
        definition.setTimeout(30);

        TransactionStatus status = transactionManager.getTransaction(definition);
        try {
            userMapper.batchInsert(batch);
            transactionManager.commit(status);
        } catch (Exception e) {
            transactionManager.rollback(status);
            throw new RuntimeException("批次插入失败，事务已回滚", e);
        }
    }
}

注意几个细节：getTransaction返回的TransactionStatus要保存好，后续commit和rollback都必须使用同一个status对象；setTimeout建议设置一下，防止某个批次执行时间过长一直占用连接；catch块里回滚完之后一般要重新抛出异常，让上层感知到失败。

这种方式最大的好处是灵活，坏处是要自己保证每个分支都正确提交或回滚。我在实际项目中主要用TransactionTemplate，只有遇到动态调整传播行为、事务内做异步通知后需要挂起当前事务等复杂场景，才会切换到这种底层写法。

3.4 多线程+CompletableFuture的主流程实现

上面示例里我用的是CountDownLatch，实际项目中我更推荐用CompletableFuture，代码更优雅，还能拿到每个分片的执行结果和异常信息，不必额外维护线程安全的集合来收集错误。

java复制public ImportResult parallelInsertWithCompletableFuture(List<UserInfo> allData, ExecutorService executor) {
    List<List<UserInfo>> batches = partition(allData, BATCH_SIZE);

    List<CompletableFuture<BatchResult>> futures = batches.stream()
            .map(batch -> CompletableFuture.supplyAsync(() -> insertBatch(batch), executor))
            .collect(Collectors.toList());

    // 等待所有任务执行完毕，join会阻塞主线程直到全部完成
    CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join();

    int successCount = 0;
    int failCount = 0;
    List<Throwable> errorList = new ArrayList<>();

    for (CompletableFuture<BatchResult> future : futures) {
        try {
            BatchResult result = future.get();
            successCount += result.getSuccessCount();
            failCount += result.getFailCount();
            if (result.getThrowable() != null) {
                errorList.add(result.getThrowable());
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } catch (ExecutionException e) {
            failCount += BATCH_SIZE;
            errorList.add(e.getCause());
        }
    }
    return new ImportResult(successCount, failCount, errorList);
}

private BatchResult insertBatch(List<UserInfo> batch) {
    BatchResult result = new BatchResult();
    try {
        transactionTemplate.executeWithoutResult(status -> userMapper.batchInsert(batch));
        result.setSuccessCount(batch.size());
    } catch (Exception e) {
        result.setFailCount(batch.size());
        result.setThrowable(e);
        log.error("批量插入事务回滚完成，本批数据: {}", batch.size(), e);
    }
    return result;
}

CompletableFuture.allOf(...).join()的语义就是等待所有子任务结束。future.get()可以拿到每个任务的结果对象，异常信息通过ExecutionException.getCause()取到真实异常。这套流程不用自己写CountDownLatch，也不用维护同步集合，代码可读性高很多。

4. 线程池参数与MySQL批量写入优化

4.1 线程池不是越大越好：连接池是硬约束

多线程插入的性能瓶颈往往不是CPU，而是数据库连接池和数据库本身的写入能力。很多人上来就把线程池核心线程数配成32、64，结果数据库连接池最大只有10，大量线程在排队等连接，性能不升反降。

合理的做法是让线程池数量和连接池容量联动。HikariCP的默认maximumPoolSize是10，如果线程池配8个核心线程，就会占满连接池中的大部分连接，其他业务模块查数据库都可能饿死。我常用的建议是：

• 如果数据库连接池maximumPoolSize是10，线程池核心线程数配4到6，留出余量给其他操作
• 如果连接池调到了20，线程池可以配8到12
• 线程数再往上加，收益会急剧下降，因为MySQL单个实例的写入能力有限，所有连接最终都要转换到磁盘和redo log的写入上

线程池的阻塞队列也要选对。批量插入任务是明确的CPU等待型任务，建议用有界队列ArrayBlockingQueue，拒绝策略用CallerRunsPolicy。主线程自己执行多余任务虽然会拖慢整体速度，但至少不会丢数据，比直接拒绝好得多。

4.2 MySQL批量插入必须注意的三个参数

批量插入写了一大堆代码，如果MySQL和JDBC配置没跟上，性能还是会差很多。这里三个参数是我每次做这类需求必检查的。

第一个是JDBC URL里的rewriteBatchedStatements=true。这个参数极其关键，它让JDBC驱动把多次addBatch()的SQL在服务端重写成一条多值INSERT语句，极大减少网络交互和SQL解析次数。不加这个参数时，大批量通过JDBC Batch执行的数据其实仍然是一条一条发给MySQL的，性能提升非常有限。加上之后，批量插入性能通常能再翻几倍。

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true

第二个是max_allowed_packet。多值INSERT生成的一条SQL可能几百KB甚至几MB，如果超过MySQL的max_allowed_packet上限，会直接报Packet for query is too large。这个参数在MySQL服务端和JDBC连接串里都有，建议统一设置到64MB或128MB。当然，比起无限调大这个值，更好的方式是控制单批数据条数在500~2000之间。

第三个和MyBatis相关。如果项目用MyBatis-Plus的saveBatch，本质上是把多条INSERT VALUES累积到一条SQL里，批量条数太大会生成超长SQL。如果自己手写Mapper XML，建议控制foreach的集合大小，配合批量条数统一管理，不要无脑塞几万条。

4.3 幂等与并发冲突处理

多线程并行插入同一张表，最怕的不是慢，而是重复数据和唯一键冲突。目标表如果有唯一索引，多个线程同时插入相同业务字段时，可能有一个线程成功，另一个线程立即爆出DuplicateKeyException。

面对这类问题，最好在批量写入之前就做好数据清洗和去重。单机环境内存里去重速度很快，比如按业务唯一键构造Set再过滤List；分布式环境则需要依赖数据库的唯一索引兜底。

MySQL里处理“存在则更新，不存在则插入”有现成语法INSERT ... ON DUPLICATE KEY UPDATE，但这种写法在高并发下容易产生锁竞争，性能并不理想。如果业务允许，我更倾向于“先批量查一遍已存在的唯一键，再只插入不存在的部分”，把冲突概率前置处理掉，让实际写入的SQL保持最干净的纯INSERT。

大数据量的搬数作业还需要考虑主从延迟。主库写入成功，从库可能还没同步到，如果此时有查询逻辑依赖刚插入的数据，可能读到不一致状态。批量导入业务如果允许延迟可见，这个点影响不大；但如果导完数据后立刻要查询报表，就要评估是否强制走主库或延迟反馈导入完成时间。

4.4 分批事务粒度怎么定

前面反复提到“每批500到2000条”，这个值不是拍脑袋定的。事务粒度大小的取舍逻辑是：批次太小，事务提交频率高，总提交开销大，性能上不去；批次太大，单事务执行时间长，锁持有时间长，失败后要重试的数据量也大。

我通常这样定：先看单条数据的大小，假设平均每条500字节，500条一批大概是250KB，即使拼成一条多值SQL也不会特别长；如果单条数据带大文本字段有10KB，那一批顶多100到200条就很大了，需要往下调。

再结合实际执行时间，保证单批事务在几十毫秒到一百多毫秒内完成，这样即使某个批次失败需要重试，成本也可控。一个特别漫长的单批次事务，一旦执行到一半失败回滚，整个事务期间持有的锁全部白费，对所有并发操作都是灾难。

还要注意分片与事务的关系：一个分片到底包含多少批？我的建议是最简单的方式就是把每个分片当一批，一个分片一个事务。这样失败重试的单位清晰，日志也容易定位是哪个分片出问题。

5. 常见问题排查与避坑实录

5.1 高频报错排查清单

多线程批量插入在实际运行中会遇到各种奇奇怪怪的报错，这里我按现象、原因、处理方式整理了一张速查表，基本都是我从项目现场搬回来的：

这个表格覆盖了绝大多数“并发批量插入”的现场报错。排查顺序我建议先看连接池和线程池的配置是否匹配，再看分片规则是否有重叠，最后看单批SQL是否触碰数据库参数限制。

5.2 多线程事务的“不可能三角”

做过一段时间并发编程后会逐渐意识到，多线程写库这件事存在一个“不可能三角”：

事务原子性、并行性能、实现复杂度，三者很难同时兼顾。

如果想保留全局原子性，最简单的方式就是串行执行，所有数据放进一个大事务，要么全成要么全败，但性能必然大打折扣。如果追求高性能，就必须拆事务，拆了之后全局原子性就没了，只能做到分片原子性。如果想同时兼顾全局原子性和性能，就需要分布式事务或者两阶段提交之类的重型方案，实现复杂度直接上升几个量级，而且对这些“批量导入”场景来说往往得不偿失。

所以大多数时候，我们在工程上接受的是：并行执行 + 分片短事务 + 失败重试 + 对账补偿。每个分片保证原子，分片之间的数据一致性靠“整体任务重跑一遍”来修复。因为批量导入通常都是幂等操作，重跑的成本低于维护一个全局大事务的成本。

这个认知想通了，也就不会再纠结为什么自己的@Transactional回滚不了所有子线程数据了——那本来就是一个设计上不该追求的方案。

5.3 如果业务坚持要“全部成功才提交”怎么办

遇到过不少业务方说“这批数据必须全部成功，有一个失败就全部回滚，不能遗留半截”。这种诉求在“并发批量插入”场景下其实很危险，但我有一个稳妥的替代流程可以分享。

不要用事务去保证，而是用“先校验、后分批、最后写”的流水线来保证。在正式插入之前，把所有数据在内存中做完整校验：必填字段、唯一键、枚举值、长度、格式，全部过一遍。任何一条数据有问题，直接在预校验阶段拦截，整个任务不进入插入阶段，这就能做到“全部合法才落库”。

预校验通过后，再走并行批量插入。写入期间如果仍然出现极少数异常（比如并发冲突、数据库临时故障），就让失败批次进入重试队列。重试几次后依然失败的，标记出来给人处理，但其余合法数据已经成功落库。

严格来说这不算“全局事务”，但对业务方来说，效果已经非常接近：合法数据全部写入，非法数据一个都不写入，还能通过失败明细表跟踪问题数据。对海量导入场景来说，这比追求一个大事务高效得多。

5.4 写数据前先做轻量校验，是一笔稳赚不赔的投资

最后讲一个我每次都要强调的经验：无论代码怎么写，插入之前一定要做轻量数据校验。很多人图省事，把Excel里拿到的数据直接丢给SQL，等到数据库报错才回头修数据，这在并行插入场景下非常痛苦。

因为多线程环境下，一条脏数据可能导致整批500条全部回滚，如果这个批次刚好卡在中间，后续分片可能已经执行了一部分，你不得不先纠正脏数据再重跑失败批次，日志和业务状态都可能变得一团糟。

我现在的做法是在分片之前先跑一个validateAndClean(List<UserInfo> data)方法，把能清洗的清洗掉，比如空字符串转null、日期格式统一、字段长度截断；把不能清洗的直接过滤出来单独记录，并在导入完成后生成一个“问题数据清单”反馈给上游。这个投入通常只占用总耗时很小比例，但能省掉后续大量排障和重跑的时间。

6. 最后的实践体会

这套方案在我经手的多个项目中反复落地过，从最初Excel导入，到后来定时任务跑批、表数据迁移，核心流程基本没变：先批量，再并行，最后用编程式事务把每个分片的边界卡死。回头总结，最大的经验其实不是哪个类或哪个注解，而是对“事务边界”和“并发资源”的敬畏。

@Transactional失效不是Spring的缺陷，而是它压根没有给你提供跨线程事务的能力。与其硬要它做到全局原子，不如顺着它的模型，把事务粒度拆分到每个线程、每个分片内部。手动事务方案真正解决的问题，不止是让代码不再报错，更是让每一个数据分片的生命周期清晰可控：谁负责开事务，谁负责提交，谁负责回滚，失败之后怎么重试，全部在代码层面一目了然。

多线程批量插入这件事，真正难的不是写代码，而是想明白事务边界放哪、线程池和连接池怎么配合、失败之后如何兜底。把这几个问题想透了，以后再遇到百万级数据导入，根本不会慌。