PageableExecutionUtils.getPage 의 최적화 로직만 따로 뺀 count 메소드입니다.

1. 갱신된 강의자료에도 나와 있듯이, fetchResult, fetchCount 등의 메소드는 deprecated 예정입니다. 또한 해당 메소드는 Page 타입을 반환하기 때문에 Page 타입을 직접적으로 조작해야 한다는 제약이 있습니다. 이걸 잘 쓰면 되는데, Page 의 시작번호 등 제약도 있어서 저는 회사에서 Page 를 따로 만들어서 사용하거든요. 그래서 search 메소드와 count 메소드는 항상 분리하고 있습니다.
   2. 그런 점에서 count 만 최적화하는 로직만 베껴서 만든 최적화 메소드입니다.

3. 실제로 count 구문을 실행하기 위한 메소드입니다. 필요에 따라서 public 으로 만들어도 될 것 같네요.

// count 실행 메소드
private Long countByCond(MemberSearchCond cond) {
    return query
            .select(member.countDistinct())
            .from(member)
            .where(
    usernameEq(cond.getUsername()),
    teamNameEq(cond.getTeamName()),
    ageGoe(cond.getAgeGoe()),
    ageLoe(cond.getAgeLoe())
            )
            .fetchOne();
}

4. 최적화 로직을 베낀 메소드입니다.

    

   1. 스프링 데이터 JPA 는 아래 코드와 같이 page, size 값이 null 이 아니고, 적절한 범위에 있는지를 판단하여 isPaged 라는 분기를 만듭니다. 참고로 코드를 분석하면서 내린 뇌피셜이니 혹시 틀리다면 말씀해주세요.

       

   2. page 가 0 이 아니라 1 부터 시작하는 건 제 취향입니다. 회사에서 그렇게 쓰고 있거든요. 필요에 따라 0 부터 시작하도록 바꾸는 건 어렵지 않을 것 같습니다.

public Long countByCondOptimization(List<?> content, MemberSearchCond cond, Long page, Long size) {

    boolean isPaged = page != null && size != null && page > 0 && size > 0;
    long offset = isPaged ? (page - 1) * size : 0L;
    long contentSize = content.size();

    if (!isPaged || offset == 0) {
        if (!isPaged || size > contentSize) {
            return contentSize;
        }
        return this.countByCond(cond);
    }

    if (contentSize != 0 && size > contentSize) {
        return offset + contentSize;
    }
    return this.countByCond(cond);
}

5. 이렇게 하여 count 쿼리를 리스트 조회 쿼리와 분리하여 재사용성을 높이면서, 성능도 최적화할 수 있습니다.
   감사합니다.