JPA @ManyToMany关联分页查询优化：避免N+1与全表加载

针对@ManyToMany关联下分页查询遇到的N+1问题和全表加载性能瓶颈，以下是几种实用优化方案：

方案1：分两次查询（先分页取ID，再批量加载关联） #

这是最稳妥的方案，核心逻辑是先分页获取Text的主键ID，再通过ID批量查询Text并同时加载关联的Country，彻底规避全表关联和N+1问题。

实现步骤： #

1. 在JPA Repository中添加两个方法：

// 分页查询Text的ID列表
Page<Long> findAllIds(Pageable pageable);

// 通过ID集合查询Text并关联加载Country
@EntityGraph(attributePaths = "countries")
List<Text> findByIdIn(Collection<Long> ids);

2. 业务层组装分页结果：

// 第一步：分页获取Text的ID
Page<Long> textIdsPage = textRepository.findAllIds(pageable);

// 第二步：批量查询包含Country的Text数据
List<Text> texts = textRepository.findByIdIn(textIdsPage.getContent());

// 组装成标准Page对象返回
Page<Text> textPage = new PageImpl<>(texts, pageable, textIdsPage.getTotalElements());

该方式仅执行3次查询：count统计、ID分页查询、关联数据查询，性能完全可控，不会加载全表数据。

方案2：JPQL子查询实现分页+关联查询 #

通过子查询先完成Text的分页筛选，再关联查询对应Country，避免先全表关联再分页的低效逻辑。

Repository方法示例： #

@Query(value = "SELECT t FROM Text t JOIN FETCH t.countries WHERE t.id IN (" +
               "SELECT t2.id FROM Text t2 ORDER BY t2.id) ",
       countQuery = "SELECT COUNT(t) FROM Text t")
Page<Text> findAllWithCountries(Pageable pageable);

这里的核心是子查询先执行Text的分页逻辑，外层查询仅关联已分页后的Text对应的Country数据，不会触发全表关联。

方案3：配置批量懒加载（降低N+1影响） #

如果不想修改查询逻辑，可以通过@BatchSize注解让Hibernate批量加载关联的Country，把N+1查询变成1+N/批量大小的查询，大幅减少查询次数。

修改Text实体的关联字段： #

@ManyToMany(fetch = FetchType.LAZY)
@BatchSize(size = 20) // 批量大小建议和分页pageSize保持一致
private Set<Country> countries = new HashSet<>();

比如每页20条数据，Hibernate会一次性查询这20条Text对应的所有Country，仅多执行1次查询，而非20次，性能提升显著。

方案4：使用DTO投影（按需查询字段） #

如果只需要Text和Country的部分字段，可以定义DTO类，通过JPQL直接查询所需字段，避免加载整个实体，进一步提升性能。

示例： #

1. 定义DTO类：

public record TextCountryDto(Long textId, String textContent, Set<String> countryNames) {}

2. Repository查询方法：

@Query("SELECT new com.example.dto.TextCountryDto(t.id, t.content, c.name) " +
       "FROM Text t JOIN t.countries c ")
Page<TextCountryDto> findAllTextCountryDtos(Pageable pageable);

这种方式查询的数据量更小，分页逻辑直接作用在Text上，不会出现全表关联问题。

内容的提问来源于stack exchange，提问作者Clément Picou