SpringBoot JPA使用saveAll批量保存遇唯一约束冲突跳过不回滚方案

很多人一开始想在外层捕获唯一约束抛出的异常来跳过冲突条目，但在批量saveAll场景下这个思路从根上就行不通：原生saveAll是挂载在单事务上下文下执行的，只要任意一条触发唯一约束冲突，整个事务会被直接标记为回滚状态，哪怕你catch住了异常，也根本提交不了剩余的正常条目，更别说跳过单条继续操作了。

以下是匹配两种业务要求的可落地实现路径，全部适配批量写入场景，没有退化为单条循环save的低性能方案：

一、冲突即跳过模式的实现 #

这种模式下要求冲突条目完全不做任何操作，正常条目正常落库，有两种适配批量场景的实现方式：

1. 预查询过滤法（无侵入、性能最优） #

因为表已经有明确的多字段唯一约束，完全可以在写入前先把待写入列表里的所有唯一字段组合抽出来，通过一次批量元组查询把已经存在的条目筛掉，剩下的纯新增集合直接走原生saveAll落库。

• 写法示例（以唯一约束为user_id + order_no的订单表为例）：
  首先在Repository里定义支持元组匹配的查询方法：

public interface OrderRepository extends JpaRepository<Order, Long> {
    @Query("select o from Order o where (o.userId, o.orderNo) in :uniqPairs")
    List<Order> findExistingEntries(@Param("uniqPairs") List<Object[]> uniqPairs);
}

业务层处理逻辑：

1. 把待保存的订单列表，按userId + orderNo的格式组装成List<Object[]>的唯一组合列表
2. 调用上述查询方法，拿到数据库中已经存在的条目集合
3. 从待写入列表里把已经存在的条目剔除，得到纯新增的差集
4. 把差集传入saveAll正常落库

• 适用场景：待写入批量规模在10万条以内，预查询耗时在可接受范围内的场景，这种方法从根源上避免了唯一约束冲突，完全不会出现事务污染的问题。

2. 小事务块隔离法（适合超大规模批量场景） #

如果待写入的数据量太大，一次全量预查询会拖慢整体性能，就把原本的整包saveAll按每200-500条的粒度拆成独立的小事务块，每个块单独提交：

• 每个小事务块的执行要标记为@Transactional(propagation = Propagation.REQUIRES_NEW)，避免和外层大事务的上下文绑定
• 块内正常执行saveAll，如果整个块抛出唯一约束相关的异常，就把块内的条目拆成单条逐次保存，单条触发冲突就跳过，无冲突的正常入库
• 实践参考：块大小不要设得太小（低于100条会因为频繁开/关事务拉低性能），也不要太大（超过1000条会导致块内冲突时的逐次校验成本过高）

二、存在即更新的Upsert模式实现 #

如果接受冲突时更新已有条目的逻辑，这种模式的批量性能比跳过模式高很多，适合对写入延迟要求高的场景：

1. Hibernate 6.0+ 原生批量Upsert #

Hibernate 6.0及以上版本已经原生支持数据库层面的upsert语法，不需要自己写原生SQL：

• 在实体类上通过@org.hibernate.annotations.Upsert注解标记冲突时需要更新的字段，同时保留原有的多字段唯一约束定义
• 直接调用原生saveAll即可，Hibernate会自动根据数据库类型生成对应的INSERT ... ON DUPLICATE KEY UPDATE（MySQL）、ON CONFLICT DO UPDATE（PostgreSQL）、MERGE INTO（Oracle）语法，在数据库层面完成冲突检测和更新，没有Java层的额外查询开销

2. 低版本Hibernate兼容方案（5.x版本） #

如果用的是Hibernate 5.x版本，不支持原生@Upsert注解，可以通过定义原生批量SQL的方式实现：

• 以MySQL为例，在Repository里定义批量upsert方法：

@Modifying
@Query(value = "INSERT INTO order_info (user_id, order_no, update_time) VALUES :tuples " +
        "ON DUPLICATE KEY UPDATE update_time = VALUES(update_time)", nativeQuery = true)
void batchUpsert(@Param("tuples") List<Object[]> tuples);

• 注意：SQL里的冲突判断字段要和表上定义的多字段唯一约束完全匹配，避免因为唯一键识别错误导致的锁表问题

落地时的通用避坑点 #

• 绝对不要在大事务的最外层全局捕获DataIntegrityViolationException就直接继续操作：触发这个异常时JPA的持久化上下文已经被标记为脏状态，必须显式调用EntityManager.clear()清理上下文，否则后续的所有持久化操作都会抛出事务必须回滚的错误
• 开启Hibernate批量写入的基础配置，否则哪怕用了saveAll也会退化成单条SQL逐条执行，性能会差一个数量级，对应的配置如下：

spring:
  jpa:
    properties:
      hibernate:
        jdbc:
          batch_size: 50
        order_inserts: true
        order_updates: true
        batch_versioned_data: true

• 当批量写入规模超过10万条时，优先选数据库层面的原生upsert方案，不要在Java层做逐次异常捕获或者预查询过滤，否则两次数据库交互的开销会把整体写入性能拉低一半以上

内容的提问来源于stack exchange，提问作者Safari