Code
실제 코드가 아닌 예시 코드입니다.
@Table(name = "community_post")
@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Post {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String subject;
private String content;
}
postRepository.findAll(PageRequest.of(0, 10));
상황
Post(게시물) 을 Pagenation 사용하여 데이터를 조회하는 중에 데이터가 9개 이하일 때는 하나의 쿼리가 나가지만 10개 이상일 경우에는 쿼리가 두개나가는 현상이 발생하였다.
비교
데이터가 9개 이하인 경우
데이터가 10개 이상인 경우
페이지 크기가 전체 데이터 개수보다 큰 경우, 페이지네이션에 대한 정보를 얻기 위해 count query를 실행하는 것은 불필요하다. 먼저 데이터를 가져온 후 영속성 컨텍스트에서 페이지 size가 전체 데이터 개수보다 적은 경우에는 count query를 실행한다. 페이징 처리를 할 때 count query가 있어야 전체 페이지를 구할 수 있어서 필요하다.
❗️마지막 페이지인 경우
마지막 페이지의 경우에도 count query를 실행하지 않는다. 동일한 이유이다.
실제 Paging 코드
결론
Count Query가 발생하는 지에 대한 여부는 중요하다. 왜냐하면 Count Query는 full table scan 이기 때문이다. 그런데 Spring JPA 에서 알아서 최적화를 해준다... 테스트 중에 쿼리 수가 예상과 달라 알아보았는데, paging 원리에 대해서 알게되어서 유익했던 것같다. 다만 join 되어있을 시 고려해야할 부분이 많이 있다. 이는 나중에 포스팅할 것이다.
'개발 이야기 > Spring' 카테고리의 다른 글
Spring WebClient 적용기 (1) | 2024.04.26 |
---|---|
ResponseEntityExceptionHandler 사용하는 이유 (1) | 2024.03.15 |
Spring ThreadPoolTaskExecutor @Async 비동기 (1) | 2024.02.20 |
Spring Profile 개발 서버와 운영 서버 분리, Environment Configurations (0) | 2024.02.03 |