Spring Boot中如何用Criteria API分页查询关联集合避免N+1问题

核心问题分析 #

当用JOIN FETCH或Entity Graph查询带@OneToMany关联的实体A时，Hibernate会因关联数据导致结果集行数膨胀（一条A对应多条B就会返回多条重复A的记录），此时分页参数会作用在膨胀后的结果集上，导致数据库层面的分页失效，变成内存分页。而单纯用Criteria不做关联抓取又会触发N+1查询。

最优解决方案 #

1. 分步查询：先分页查主实体A，再批量抓取关联集合B #

这是最稳妥的方案，分三步实现：

• 第一步：用Criteria或JPQL分页查询仅包含实体A主键的结果，这一步是数据库层面的物理分页，完全符合预期分页逻辑。
• 第二步：根据第一步拿到的所有A的ID，批量查询关联的B集合，并按A的ID分组。
• 第三步：查询完整的A实体，将分组后的B集合手动关联到对应A上。

示例代码：

// 第一步：分页查询A的ID列表
CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<Long> idQuery = cb.createQuery(Long.class);
Root<A> aRoot = idQuery.from(A.class);
idQuery.select(aRoot.get("id"));
// 添加分页参数
TypedQuery<Long> typedIdQuery = entityManager.createQuery(idQuery)
        .setFirstResult(page * size)
        .setMaxResults(size);
List<Long> aIds = typedIdQuery.getResultList();

// 第二步：批量查询所有关联的B，并按A的ID分组
CriteriaQuery<B> bQuery = cb.createQuery(B.class);
Root<B> bRoot = bQuery.from(B.class);
bQuery.where(bRoot.get("a").get("id").in(aIds));
List<B> bList = entityManager.createQuery(bQuery).getResultList();
Map<Long, List<B>> bMap = bList.stream()
        .collect(Collectors.groupingBy(b -> b.getA().getId()));

// 第三步：查询完整的A实体，并关联B集合
CriteriaQuery<A> aQuery = cb.createQuery(A.class);
Root<A> aFullRoot = aQuery.from(A.class);
aQuery.where(aFullRoot.get("id").in(aIds));
List<A> aList = entityManager.createQuery(aQuery).getResultList();
aList.forEach(a -> a.setB(bMap.getOrDefault(a.getId(), Collections.emptyList())));

这种方式既避免了N+1，又保证分页是数据库层面的，不会出现内存分页问题，性能可控。

2. 使用Hibernate的DISTINCT_ROOT_ENTITY配合JOIN FETCH（需谨慎） #

如果不想分步查询，可以在JPQL/Criteria中使用DISTINCT_ROOT_ENTITY消除重复的A实体，同时结合JOIN FETCH抓取关联集合。注意：

• 必须在查询中添加DISTINCT，JPQL用SELECT DISTINCT a FROM A a JOIN FETCH a.b，Criteria需设置setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY)。
• 需设置HINT_PASS_DISTINCT_THROUGH为false，让数据库执行DISTINCT，保证分页在数据库层面完成。

示例JPQL代码：

TypedQuery<A> query = entityManager.createQuery(
        "SELECT DISTINCT a FROM A a JOIN FETCH a.b WHERE ...", A.class)
        .setFirstResult(page * size)
        .setMaxResults(size);
query.setHint(QueryHints.HINT_PASS_DISTINCT_THROUGH, false);
List<A> aList = query.getResultList();

该方案适合关联集合数据量较小的场景，若B集合数据量大，膨胀后的结果集会导致分页查询变慢，需根据实际场景评估。

3. 优化@BatchSize（并非最差选择） #

@BatchSize是折中方案，它将N+1查询变成1+M查询（M为批量查询次数，由size决定）。如果分页每页数据量不大（比如每页20条），设置@BatchSize(size = 50)可将查询次数控制在2次（一次查A，一次批量查所有A对应的B），性能表现可观。

可在实体A的关联字段上添加：

@OneToMany(mappedBy = "a")
@BatchSize(size = 50)
private Collection<B> b;

或在Hibernate配置中全局设置：

hibernate.default_batch_fetch_size=50

该方案代码侵入性低，无需修改查询逻辑，适合快速解决问题，不必过度排斥。

方案选择建议 #

• 追求最优性能和严格物理分页，优先选分步查询，尤其适用于关联集合数据量大的场景。
• 关联集合数据量小且不想修改太多查询逻辑，可用DISTINCT_ROOT_ENTITY + JOIN FETCH组合。
• @BatchSize作为兜底方案，在大多数中小数据量场景下足够好用。

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