JPA Specification禁用总数查询
背景
JPA specification查询使用Pageable进行分页查询，返回的Page对象会查询数据的总数用于计算总页数。这种方式就存在弊端，用户每点击一页都会执行一次总数查询。在数据库数据过多的情况下，这种查询方式通常会伴随着慢查询。
优化方案
通常过大的数据就没必要去计算总页数。对于用户来说去查询最后一页的数据并没有多大意义。用户可以查询采用精确查询，比如根据手机号码查询指定用户的信息。前端分页可以采用向前翻和向后翻的方式。后端只需要根据LIMIT查询的结果，返回给前端是否存在下一页数据即可。
通过查看源码，我们发现JPA并没有提供传递Pageable对象，返回List集合的方法。接下来我们考虑一下是不是有办法把Specification的总数查询给禁用掉，然后实现原生查询 SELECT * FROM xxx LIMIT N, M的功能。
public interface JpaSpecificationExecutor<T> {
List<T> findAll(Specification<T> spec);
Page<T> findAll(Specification<T> spec, Pageable pageable);
List<T> findAll(Specification<T> spec, Sort sort);
}
JPA源码分析
首先看一下JPA是怎么实现总数查询的，查看SimpleJpaRepository的findAll实现。
/**
* Returns a {@link Page} of entities matching the given {@link Specification}.
*
* @param spec
* @param pageable
* @return
*/
public Page<T> findAll(Specification<T> spec, Pageable pageable) {
// 根据复杂条件获取TypedQuery
TypedQuery<T> query = getQuery(spec, pageable);
// pageable为空则执行查询获取查询结果
// pageable不为空则执行readPage
return pageable == null ? new PageImpl<T>(query.getResultList())
: readPage(query, getDomainClass(), pageable, spec);
}
这部分的逻辑很简单，主要是根据复杂条件查询参数获取TypedQuery对象。最后根据是否指定分页参数来决定返回的结果。由于我们这里关注的是分页情况下的总数查询，那么接着看readPage方法。
/**
* Reads the given {@link TypedQuery} into a {@link Page} applying the given {@link Pageable} and
* {@link Specification}.
*
* @param query must not be {@literal null}.
* @param domainClass must not be {@literal null}.
* @param spec can be {@literal null}.
* @param pageable can be {@literal null}.
* @return
*/
protected <S extends T> Page<S> readPage(TypedQuery<S> query, final Class<S> domainClass, Pageable pageable,
final Specification<S> spec) {
// 设置LIMIT参数
query.setFirstResult(pageable.getOffset());
// 设置每页数量
query.setMaxResults(pageable.getPageSize());
// 分别执行数据查询和总数查询，封装成Page对象
return PageableExecutionUtils.getPage(query.getResultList(), pageable, new TotalSupplier() {
@Override
public long get() {
return executeCountQuery(getCountQuery(spec, domainClass));
}
});
}
此时，我们已经发现了JPA默认查询总数的具体地方，那么假如我们不需要这个总数查询，只需要将该方法通过子类重写就可以了。以下为具体的代码实现。
/**
* 分页查询，不查询总数
**/
@Repository
public class CriteriaNoCountRepository {
/**
* 注入JPA实体管理器用于自定义Repository的初始化
*/
@PersistenceContext
protected EntityManager entityManager;
public <T, ID extends Serializable> Page<T> findAll(Specification<T> spec, Pageable pageable, Class<T> clazz){
// 创建对象
SimpleJpaNoCountRepository<T, ID> noCountRepository = new SimpleJpaNoCountRepository<T, ID>(clazz, entityManager);
// 执行查询方法
return noCountRepository.findAll(spec, pageable);
}
/**
* 创建一个内部类 继承SimpleJpaRepository，重写readPage方法
*/
public static class SimpleJpaNoCountRepository<T, ID extends Serializable> extends SimpleJpaRepository<T, ID> {
public SimpleJpaNoCountRepository(Class<T> domainClass, EntityManager entityManager) {
super(domainClass, entityManager);
}
/**
* 不对总数据进行查询
* 根据查询的结果估算总数用于算出hasNext hasPrevious
*/
@Override
protected <S extends T> Page<S> readPage(TypedQuery<S> query, Class<S> domainClass, Pageable pageable, Specification<S> spec) {
query.setFirstResult(pageable.getOffset());
query.setMaxResults(pageable.getPageSize());
// 分页总数查询
List<S> content = query.getResultList();
// 分页查询结果小于查询数 page-> hasNext = false
if (content.size() < pageable.getPageSize()) {
// 查询结果小于需求数，说明没有下一页
return new PageImpl<S>(content, pageable, (pageable.getPageNumber() + 1) * pageable.getPageSize());
}
// page -> hasNext = true;
return new PageImpl<S>(content, pageable, (pageable.getPageNumber() + 1) * pageable.getPageSize() + 1);
}
}
}
这里的总数计算公式是怎么来的呢？我们这里最终的目的是为了返回正确的hasNext和hasPrevious字段，由于PageImpl类未提供set方法让我们设置这两个字段，而是通过Pageable和count两个字段算出，因此我们需要通过计算一个假的count传递进去。
@Override
public boolean hasNext() {
return getNumber() + 1 < getTotalPages();
}
我们接着看一下PageImpl的实现，可以看到hasNext()方法判断逻辑很简单，就是当前页小于总页数，就存在下一页。
因此我们总数只需要根据当前页数进行计算
hasNext = true -> count = (pageNumber + 1) * pageSize + 1
hasNext = false -> count = （pageNumber + 1) * pageSize
补充说明
这里计算hasNext的逻辑是根据结果数量和预期每页数量做的比较。如果查询小于每页需要的数量则认为没有下一页。当总数量是每页数量的整数倍，并且翻到最后一页的时候，这个判断逻辑可能会出现误判。举个例子，数据库中有10条数据，我们进行分页查询每页查询两条，当查询到第五页的时候，由于此时返回的也是2条数据，那么根据刚刚的逻辑，hasNext=true。然而再去进行查询，已经查询不到数据了。
