为何Spring JPA的saveAll有时无法启用批量更新？

这个问题的核心原因其实是Hibernate对不同状态的实体采取了完全不同的处理逻辑，咱们一步步拆解清楚：

1. 自行创建的Data对象：瞬时态（Transient）实体的处理 #

你自己new出来的Data对象，在Hibernate眼里属于瞬时态（Transient）——也就是Hibernate完全没见过这些对象，不知道它们对应的数据库记录是否存在。

当你调用saveAll时，Hibernate会对每个实体执行以下操作：

• 先执行一条select语句，检查这个实体对应的记录是否已经存在（默认通过主键是否为null或者@Version字段判断，不同主键生成策略逻辑略有不同）
• 确认是新实体后，才会执行插入操作

这就解释了你看到的日志：大量的Loader查询日志，1500条JDBC语句里大部分是检查性的select，真正的插入批次只有3次——大部分时间都耗在了逐个检查实体是否存在的过程中，自然速度慢到离谱。

2. 从数据库查询出来的Data对象：持久态（Persistent）实体的处理 #

通过findAllByBatchId查询得到的Data对象，属于持久态（Persistent）——这些对象已经被Hibernate加载到当前Session的一级缓存中，Hibernate会全程跟踪它们的状态变化。

当你修改这些对象的字段后调用saveAll，Hibernate的处理逻辑完全不同：

• 不需要再去数据库查询实体是否存在（Hibernate确定这些对象对应的记录肯定在数据库里）
• 在事务提交或Session flush时，Hibernate会自动收集所有被修改的"脏对象"，然后批量生成update语句执行

这就是为什么这个场景下只需要少量JDBC批次，耗时仅8秒——没有了额外的检查开销，批量更新的效率自然很高。

额外优化建议（针对瞬时态实体的批量插入） #

如果你的业务场景就是要批量插入自行创建的实体，想要提升性能，可以试试这些方案：

• 调整主键生成策略：避免使用IDENTITY（比如MySQL的自增主键），这种策略会强制Hibernate禁用批量插入，改用SEQUENCE或TABLE策略
• 配置Hibernate批量参数：在配置文件里设置spring.jpa.properties.hibernate.jdbc.batch_size=50（值根据你的数据量调整，一般50-100合适）
• 直接使用EntityManager#persist批量处理：persist方法专门处理瞬时态实体，不会执行existence check，比saveAll更适合纯插入场景

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