Hibernate Criteria分页问题：Fetch Join后无法获取预期数量的Distinct实体

这个问题我之前也踩过坑，核心原因很明确：分页操作是作用在关联查询后的笛卡尔积结果集上，而非去重后的根实体。当你用FetchMode.JOIN关联employees集合时，Hibernate会生成一条左连接SQL，把Company和Employee的数据合并返回——比如第一个公司有18个员工，结果集里前18条记录都是这个公司。这时候你设置setMaxResults(20)，数据库只会返回这20条关联记录，后续DISTINCT_ROOT_ENTITY在内存中去重后，自然就只剩3个公司了。

要同时实现「准确分页获取20个Company」和「预加载Employees避免懒加载」，推荐分两步查询的方案：

方案：先分页查根实体ID，再批量查询带关联的完整实体 #

第一步：分页获取目标Company的ID列表 #

先单独查询Company的ID，这里的分页直接作用在根实体上，能确保拿到精准的20个唯一ID：

// 1. 分页查询Company的ID，确保数量准确
Criteria idCriteria = sessionFactory.getCurrentSession().createCriteria(Company.class);
idCriteria.createAlias("employees", "employees", JoinType.LEFT_OUTER_JOIN);
// 有其他过滤条件的话，在这里添加（比如where子句）
idCriteria.setProjection(Projections.distinct(Projections.id())); // 保证ID唯一
idCriteria.setFirstResult((pageNb - 1) * nbPerPage);
idCriteria.setMaxResults(nbPerPage);
List<Long> companyIds = idCriteria.list();

第二步：根据ID查询完整Company并预加载Employees #

拿到ID列表后，一次性查询这些Company，同时用FetchMode.JOIN预加载关联的员工，既保证数量准确，又避免懒加载问题：

// 2. 根据ID批量查询完整实体，预加载employees
Criteria criteria = sessionFactory.getCurrentSession().createCriteria(Company.class);
criteria.add(Restrictions.in("id", companyIds));
criteria.setFetchMode("employees", FetchMode.JOIN);
criteria.setResultTransformer(CriteriaSpecification.DISTINCT_ROOT_ENTITY);
// 如果需要保持分页顺序，记得添加和第一步相同的排序规则
List<Company> companies = criteria.list();

为什么这个方案可行？ #

• 第一步的分页直接针对Company的ID，完全不受关联集合大小影响，确保拿到20个不同的公司ID。
• 第二步通过ID批量查询，配合FetchMode.JOIN预加载员工，既解决了懒加载的N+1性能问题，又保证返回的Company数量完全符合分页要求。

如果你的项目已经升级到Hibernate 5+，也可以用JPA标准的CriteriaQuery实现类似逻辑，核心思路始终是「先分页获取根实体标识，再批量查询关联数据」。

内容的提问来源于stack exchange，提问作者Jérôme R