JPA高批量持久化场景下saveAll如何正确处理persist与merge操作

你遇到的saveAll执行前先执行SELECT的问题，本质是JPA默认的实体新状态判断逻辑不匹配你的场景：由于你使用了赋值即完成的@EmbeddedId复合主键，没有添加@Version注解，JPA无法通过主键是否为空、版本号是否存在判断实体是新增还是已存在，因此每次调用save方法都会先触发一次查询去数据库校验主键是否存在，再决定执行INSERT还是UPDATE，批量处理时就会产生N次额外查询，性能极差。

方案1：轻量实现Persistable接口，无需依赖外部存储 #

你之前的Persistable方案不需要依赖Redis做存在性校验，只需要在实体中新增一个瞬态标记位，由业务侧传入状态即可：

1. 实体类改造实现Persistable接口

@Entity
public class MyEntity implements Persistable<MyCompositeId> {
    @EmbeddedId
    private MyCompositeId id;
    // 其余业务字段省略

    @Transient // 标记为瞬态，不持久化到数据库
    private boolean isNewFlag;

    @Override
    public MyCompositeId getId() {
        return id;
    }

    @Override
    public boolean isNew() {
        return isNewFlag;
    }

    // 业务侧调用设置实体状态
    public void setNewFlag(boolean newFlag) {
        isNewFlag = newFlag;
    }
}

2. 业务层处理数据时，根据业务规则直接标记实体状态：如果是明确的新增数据设为true，明确的更新数据设为false即可。
   此时调用saveAll方法时，Hibernate会直接读取你自定义的isNew()返回值判断实体状态：

• 返回true：直接调用persist()执行INSERT，无前置查询
• 返回false：直接调用merge()执行UPDATE，无前置查询
  完全复用你已配置的批处理参数（order_inserts、batch_size等）的优化能力，不需要额外改造存储层。

方案2：业务侧无法判断状态时，用原生批量Upsert兜底 #

如果你的场景没有办法提前区分新增/更新数据，可以使用数据库原生的Upsert语法（根据你使用的数据库适配：MySQL用INSERT ON DUPLICATE KEY UPDATE、PostgreSQL用INSERT ON CONFLICT DO UPDATE、Oracle用MERGE INTO），一次性完成整批数据的新增/更新，全程无额外SELECT查询，性能远高于JPA默认的先查后改逻辑。
MySQL场景示例：

// 自定义Repository方法
@Modifying
@Query(value = "<原生UpsertSQL，批量拼接200条参数>", nativeQuery = true)
void batchUpsert(List<MyEntity> entityList);

• 你当前配置的jdbc.batch_size=20，可以根据压测结果调整到50~100，进一步提升批处理吞吐量
• 可临时开启Hibernate的SQL日志，确认批处理确实生效，没有生成单条执行的SQL语句

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