Spring Boot 2.7.2迁移至3.2.2后@BatchSize引发N+1查询异常

问题背景 #

将Spring Boot从2.7.2迁移至3.2.2（搭配hibernate-core 6.1.4.Final）后，即使在@OneToMany关联上标注了@BatchSize(size = 600)，遍历Team集合获取关联UserList时仍出现N+1查询异常：生成的SQL中IN条件的参数数量逐次递减，最终出现一条包含大量参数的查询，批量查询完全失效。

相关代码 #

业务逻辑代码 #

@Transactional(readOnly = true)
public void test() {
    Slice<Team> teamSlice = teamRepository.findAllLimit10();
    List<Team> teamList = teamSlice.getContent();
    List<Boolean> booleanList = teamList.stream()
                                        .map(team -> team.getUserList().isEmpty()) // 触发懒加载的点
                                        .collect(Collectors.toList());
}

实体关联配置 #

@Builder.Default
@Where(clause = "enabled = true")
@BatchSize(size = 600)
@OneToMany(mappedBy = "team", cascade = CascadeType.PERSIST)
private List<User> userList = new ArrayList<>();

根本解决方法 #

1. 升级Hibernate至修复版本 #

该问题大概率是Hibernate 6.1.x版本的已知bug（如批量加载逻辑与@Where注解、懒加载触发时机的兼容性问题），建议升级到Hibernate 6.2.x及以上版本。6.2.x系列修复了多个批量加载相关的缺陷，能恢复@BatchSize的正常批量查询逻辑。

2. 调整批量加载的触发方式，避免流式遍历的逐次触发 #

Hibernate的批量加载依赖会话中收集待加载的实体ID，流式遍历可能因上下文处理逻辑导致ID收集不完整。可改为提前批量初始化关联：

@Transactional(readOnly = true)
public void test() {
    Slice<Team> teamSlice = teamRepository.findAllLimit10();
    List<Team> teamList = teamSlice.getContent();
    
    // 一次性触发所有关联的批量加载
    Hibernate.initialize(teamList.stream().map(Team::getUserList).collect(Collectors.toList()));
    
    List<Boolean> booleanList = teamList.stream()
                                        .map(team -> team.getUserList().isEmpty())
                                        .collect(Collectors.toList());
}

使用Hibernate.initialize()能确保Hibernate收集所有需要加载的Team ID，生成符合@BatchSize配置的批量查询SQL。

3. 结合实体图(EntityGraph)配置批量加载 #

定义实体图显式指定关联的批量加载策略，让Hibernate在查询Team阶段就规划好关联的批量加载：

第一步：在Team实体上定义命名实体图

@NamedEntityGraph(
    name = "Team.withBatchUsers",
    attributeNodes = @NamedAttributeNode(value = "userList", subgraph = "batchUsers"),
    subgraphs = @NamedSubgraph(
        name = "batchUsers",
        batchSize = 600 // 指定批量加载大小
    )
)
@Entity
public class Team {
    // 现有实体代码
}

第二步：在Repository方法上绑定实体图

@Repository
public interface TeamRepository extends JpaRepository<Team, Long> {
    @EntityGraph(value = "Team.withBatchUsers", type = EntityGraph.EntityGraphType.LOAD)
    Slice<Team> findAllLimit10();
}

这种方式能确保Hibernate按照指定的批量大小加载关联数据，避免后续遍历触发异常的N+1查询。

4. 检查全局批量加载配置 #

确保全局配置中没有覆盖@BatchSize的设置，在application.yml中添加或确认：

spring:
  jpa:
    properties:
      hibernate:
        default_batch_fetch_size: 600 # 全局默认批量加载大小，与注解值保持一致

全局配置与注解配置配合，能避免Hibernate因优先级问题忽略注解的批量设置。

对已尝试方案的补充说明 #

• @Fetch(FetchMode.SUBSELECT)：通过子查询一次性加载所有关联数据，虽能解决N+1，但本质是绕过批量加载逻辑，当Team数量较大时会生成超大子查询，性能不如正常批量加载。
• Fetch Join：因JPA规范限制，分页查询中使用fetch join会导致Hibernate在内存中处理分页，数据量大时内存占用过高，不适合生产环境。

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