【java】大数据insert的几种技术方案和优缺点

在Java项目中，尤其是使用MyBatis作为ORM框架时，批量插入（batch insert）是高频需求。常见的实现方式主要有如下几种：

方案零：单条循环插入

这是最简单粗暴的方法，循环调用单条插入方法：

for (PaymentBatchDetail detail : paymentBatchDetailList) {
    paymentBatchDetailMapper.insert(detail);
}

这种方式虽然最简单，但每次都需要和数据库建立一次连接、执行一次SQL，效率极低，可以说是反面教材了

方案一：ExecutorType.BATCH批量提交(推荐)

原理介绍

MyBatis 支持三种执行器类型（ExecutorType）：

• SIMPLE：默认，每执行一次SQL就提交一次。
• REUSE：复用预编译SQL（较少用）。
• BATCH：批量执行，将多次的SQL操作先缓存起来，最后一次性提交到数据库。

ExecutorType.BATCH 的核心思想：

多条SQL先暂存在内存中，等积累到一定数量后，一次性发送给数据库批量执行。

这种方式避免了超长的拼接SQL，提升了插入效率，也降低了单条SQL的长度风险。

代码实现

开启批量会话

// 注入SqlSessionFactory
@Autowired
private SqlSessionFactory sqlSessionFactory;

// 开启BATCH模式的SqlSession
SqlSession sqlSession = sqlSessionFactory.openSession(ExecutorType.BATCH, false);

获取Mapper，循环插入

DetailMapper mapper = sqlSession.getMapper(DetailMapper.class);
int batchSize = 1000; // 每批提交1000条
List<Detail> list = ...; // 你的数据列表

for (int i = 0; i < list.size(); i++) {
    mapper.insert(list.get(i)); // 这里调用的是单条插入的SQL
    // 每batchSize条提交一次
    if ((i + 1) % batchSize == 0 || i == list.size() - 1) {
        sqlSession.commit();
        sqlSession.clearCache();
    }
}
sqlSession.close();

Mapper XML 只需单条插入SQL

<insert id="insert" parameterType="com.tme.it.apply.entity.Detail">
    INSERT INTO payment_batch_detail (...字段...)
    VALUES (...#{xxx}...)
</insert>

优缺点分析

场景建议

• 推荐用于大数据量批量插入，如数据导入、日志归档、历史数据迁移等。
• 批次大小建议根据服务器内存和数据库压力调整（如500~2000条/批）。
• 需要每行进行数据加工的场景

小结
ExecutorType.BATCH 是MyBatis官方推荐的批量插入方式，性能优异，适用范围广，是解决大数据量insert的首选方案。

方案二：分批控制foreach批量插入的SQL长度

使用 <foreach> 标签拼接多值 SQL

这是最直观、最常见的批量插入写法。它通过MyBatis的 <foreach> 标签，将多条数据拼接成一条超长的 INSERT 语句。例如：

Mapper XML 示例

<!-- 批量插入付款批详情 -->
<insert id="insertBatch" parameterType="java.util.List">
    INSERT INTO detail (
        id,
        no,
        -- ... 省略其它字段 ...
        platform
    ) VALUES
    <foreach collection="list" item="item" separator=",">
        (
            #{item.id},
            #{item.no},
            -- ... 省略其它字段 ...
            #{item.platform}
        )
    </foreach>
</insert>

调用方式

import java.util.List;
import org.springframework.beans.factory.annotation.Autowired;
import com.tme.it.apply.mapper.DetailMapper;

@Autowired
private DetailMapper detailMapper;

// 批量插入
detailMapper.insertBatch(detailList);

分批调用

public void batchInsertByForeach(List<Detail> detailList, int batchSize) {
    int total = detailList.size();
    for (int i = 0; i < total; i += batchSize) {
        int end = Math.min(i + batchSize, total);
        List<Detail> subList = detailList.subList(i, end);
        detailMapper.insertBatch(subList);
    }
}

类比理解
你可以把这种方式理解为：

“把一沓快递单一次性交给快递员，快递员一次性录入所有单子。”
如果单子太多，快递员手忙脚乱，录入时间会变长，甚至可能出错。

foreach标签的工作原理

MyBatis 的 <foreach> 标签会将集合中的每个元素展开，拼接成一条“超长”的 SQL 语句。
比如批量插入1000条数据，最终会生成如下SQL：

INSERT INTO payment_batch_detail (col1, col2, ...)
VALUES
  (v11, v12, ...),
  (v21, v22, ...),
  ...
  (v1000_1, v1000_2, ...);

性能瓶颈

SQL字符串过长

• SQL长度限制
  数据库对单条SQL语句的长度有限制（如MySQL默认4MB），超长SQL会报错或被截断。
  但是各个数据库的可能不一致，mysql可以通过以下命令查看

SHOW VARIABLES LIKE 'max_allowed_packet';

• 网络传输压力
  客户端与数据库之间传输超大SQL，耗时明显增加。
• 内存消耗
  MyBatis 需要在内存中拼接和缓存整个大SQL，内存压力增大。

数据库解析和执行慢

• SQL解析耗时
  数据库需要解析、优化、执行这条超长的SQL，解析时间随条数线性增长，甚至更快。
• 锁表风险
  一次性插入大量数据，容易导致表锁定，影响其它业务操作。
• 回滚压力大
  只要有一条数据出错，整个SQL都会回滚，影响批量操作的原子性和健壮性。

批量过大导致JDBC驱动或数据库异常

• JDBC驱动本身对SQL长度和参数个数有限制，超过阈值时会抛出异常。

现象总结

• 数据量小时，foreach批量插入性能还不错。
• 数据量大时，SQL过长，性能急剧下降，甚至报错。
• 这类瓶颈是MyBatis和数据库本身的机制决定的，简单调大批次反而适得其反。

小结

• foreach适合小批量数据插入。
• 大数据量时，必须优化批量插入方式，否则性能和稳定性都无法保证。

优缺点分析

场景建议

• 适合中等批量插入（如几千~几万条）。
• 批次大小建议结合字段数量、单条数据长度以及数据库SQL长度上限（如MySQL 4MB）来定，一般500~1000条较安全。如果insert单行的字段太多可能需要调整到10-20条
• 对于超大批量（几十万~百万级），建议采用ExecutorType.BATCH或数据库原生导入方案。

小结
分批foreach插入兼顾了实现简易和批量性能，是老项目改造和中等数据量场景的实用方案，但不适合极大数据量。

方案三：MyBatis-Plus的saveBatch原理与适用场景

原理介绍

MyBatis-Plus 是 MyBatis 的增强工具包，极大简化了 CRUD 操作。
其中 saveBatch 方法是其批量插入的常用方案，底层实现其实是分批调用 MyBatis 的批量插入。

工作机制

• saveBatch 默认每批插入1000条（可自定义）。
• 内部采用 ExecutorType.BATCH 的 SqlSession，循环调用单条插入方法，达到批次后统一提交。
• 支持事务控制，遇到异常可回滚。

本质：

自动帮你分批、批量提交，封装了批处理的繁琐细节，兼顾性能与易用性。

代码实现

直接调用saveBatch

@Autowired
private DetailService detailService;

List<PaymentBatchDetail> list = ...; // 待插入的数据

// 默认每批1000条
detailService.saveBatch(list);

// 或自定义批次大小
detailService.saveBatch(list, 500);

核心源码片段（简化说明）

MyBatis-Plus的saveBatch大致实现如下：

@Transactional(rollbackFor = Exception.class)
public boolean saveBatch(Collection<T> entityList, int batchSize) {
    int i = 0;
    for (T entity : entityList) {
        insert(entity); // 调用单条插入
        if (++i % batchSize == 0) {
            sqlSession.flushStatements(); // 批量提交
        }
    }
    sqlSession.flushStatements(); // 提交剩余的
    return true;
}

优缺点分析

类比说明

自动驾驶的快递车

• 你只需要告诉快递车要送哪些包裹，车会自动帮你分批、规划路线、安全送达。

全自动厨房

• 你只需把菜单交给厨房，后厨会自动分批烹饪、上菜，无需你操心细节。

5.5 适用场景

• 项目已集成 MyBatis-Plus，且批量插入逻辑简单。
• 需要快速开发、减少重复劳动。
• 批量数据量中等到较大（几千~十几万条）。
• 对事务、异常处理有一定要求。

不适用场景

• 项目未使用MyBatis-Plus。
• 需要复杂的自定义SQL或批量更新/条件插入等复杂操作。
• 超大数据量（百万级以上）时，建议考虑数据库原生导入工具或更底层的批处理。

小结
MyBatis-Plus 的 saveBatch 是批量插入的“开箱即用”方案，极大提升了开发效率，适合大多数中大型数据批量插入场景。性能接近手写BATCH，且代码更优雅。

如需对比三种方案的适用范围和选择建议，请回复 6，我将为你总结三种方案的对比和最佳实践建议。

非常好，下面详细介绍方案四：insert into ... select ... 语法的原理与局限，包括原理、代码实现、优缺点和适用场景。

方案四：insert into … select … 语法(最快)

原理介绍

insert into ... select ... 是数据库的原生批量插入语法，直接在数据库层面实现数据的批量迁移、插入等操作。

基本语法：

INSERT INTO target_table (col1, col2, ...)
SELECT col1, col2, ...
FROM source_table
WHERE ...;

核心思想：

通过一条 SQL，从源表（或视图、子查询）中查询出数据，直接插入到目标表。
数据的读取和写入都在数据库内部完成，无需Java层循环插入，极大提升效率。

代码实现

直接在 Mapper XML 写 SQL

<insert id="insertFromSelect">
    INSERT INTO payment_batch_detail (col1, col2, col3)
    SELECT col1, col2, col3
    FROM temp_payment_detail
    WHERE batch_id = #{batchId}
</insert>

Java 端调用

detailMapper.insertFromSelect(batchId);

也可用于跨表、跨库（需支持）

优缺点分析

适用场景

• 表间数据迁移、归档、历史表分表等场景。
• 数据同步、数据分批导入（如临时表转正式表）。
• 数据清洗、转换（可配合SQL函数、表达式）。

不适用场景

• 需要从Java内存对象批量插入数据库。
• 需要复杂的业务逻辑、校验、转换。
• 跨库、跨系统的数据迁移（需数据库支持）。

小结
insert into ... select ... 是数据库原生的高效批量插入方案，适用于表间数据迁移、归档和大批量数据处理场景。
但不适合Java对象批量插入和复杂业务逻辑处理，通常作为数据迁移/归档的专项工具，在日常业务批量写入中使用有限。

方案五：异步队列/中间件分批入库

原理介绍

在高并发、大数据量写入场景下，直接同步写库容易造成数据库压力过大、响应延迟、甚至写入失败。
异步队列/中间件分批入库是一种解耦、削峰填谷的常用架构模式：

• 写入请求先进入消息队列（如 Kafka、RabbitMQ、RocketMQ、Redis Stream 等）
• 后端有专门的消费服务，从队列批量拉取消息，分批写入数据库
• 实现业务与数据库写入的解耦，提升系统整体吞吐量和稳定性

实现方式

发送端（生产者）

• 业务系统将待插入的数据（如订单、日志、明细等）异步写入消息队列，快速响应用户请求

消费端（消费者）

• 独立的消费服务不断从队列拉取消息，聚合到一定批量后，采用批量插入方案（如MyBatis BATCH、saveBatch等）写入数据库
• 可根据实际负载动态调整批次大小、消费速率

典型技术栈

• 消息队列：Kafka、RabbitMQ、RocketMQ、Redis Stream、ActiveMQ等
• 消费端：Spring Boot 定时拉取、Spring Cloud Stream、Flink、Spark Streaming等

伪代码示例

// 生产端
orderService.createOrder(orderVo) {
    // 业务校验
    // ...
    // 异步写入队列
    mqTemplate.send("order-insert-queue", orderVo);
}

// 消费端批量入库
@Scheduled(fixedDelay = 1000)
public void batchInsert() {
    List<Order> batch = mqTemplate.receiveBatch("order-insert-queue", 500);
    if (!batch.isEmpty()) {
        orderMapper.batchInsert(batch); // 可用ExecutorType.BATCH或saveBatch
    }
}

优缺点分析

适用场景

• 高并发写入、瞬时流量高峰（如秒杀、日志收集、物联网数据采集）
• 对写入实时性要求不高，允许秒级/分钟级延迟
• 需要解耦业务与数据库负载，提升系统可用性与弹性

不适用场景

• 强一致性、强实时性业务（如金融核心交易、实时扣款等）
• 数据量很小、并发压力低的场景

小结
异步队列/中间件分批入库是一种应对高并发、大数据量写入的架构型优化，能极大提升系统的吞吐量和稳定性。适用于需要削峰填谷、解耦写入的业务场景，但对实时性和一致性有一定影响，需要配套完善的监控、幂等和补偿机制。

Java大数据量insert五大技术方案对比与最佳实践

方案选择建议

1. 业务侧批量写入（10万级以内，需事务）

• 优先推荐：MyBatis ExecutorType.BATCH 或 MyBatis-Plus saveBatch
• 理由：易用，支持事务，适合日常业务批量写入

2. 表间大批量迁移/归档/数据清洗

• 优先推荐：insert into … select …
• 理由：数据库原生，性能极高，适合批量迁移和数据处理

3. 高并发写入，需削峰填谷

• 优先推荐：异步队列/中间件分批入库
• 理由：解耦业务与数据库，提升系统可用性和吞吐量

4. 兼容性优先、数据库多样化

• 优先推荐：foreach分批拼接SQL
• 理由：兼容多种数据库，灵活性高，适合小批量多次插入