🐞 JPA N+1 문제 - Fetch Join & EntityGraph

[문제 요약] 

• 증상: 글 목록 페이지에서 글 조회 시 Category를 건별로 추가 조회 (N+1 문제 발생) 
• 원인: JPA 쿼리에서 fetch join을 명시하지 않아 발생 
• 해결: @EntityGraph(attributePaths = “category”)로 한 번에 조회 

N+1 문제란 무엇인가?

N+1 문제는 데이터베이스 조회 시 1번의 쿼리로 N개의 데이터를 가져왔는데 연관된 데이터를 참조하기 위해 추가로 N번의 쿼리가 더 실행되는 현상을 말한다.

JPA(Hibernate)는 객체 지향적인 관점에서 데이터를 조회한다. Post를 조회할 때 연관된 Category가 있다면 JPA는 우선 Post 목록을 가져오는 쿼리를 실행한다. (1번)

그 후 각 Post 객체 내의 Category를 사용하려 할 때(또는 EAGER 설정에 의해) 각각의 Post가 가진 category_id를 조건으로 개별 쿼리를 실행하게 된다. (N번)

문제 상황 분석

기존에는 Post 목록을 조회하기 위해 JpaRepository에서 아래와 같은 JPQL 쿼리를 실행했다.
 

@Query("""
      SELECT p FROM Post p
      WHERE p.status = :status
      ORDER BY p.createdAt DESC, p.id DESC
      """)
Slice<Post> findPublishedPosts(@Param("status") PostStatus status, Pageable pageable);

실제 실행된 쿼리는 아래와 같다. 

-- 1. Post 목록 조회 (1회)
Hibernate:
  select
    p1_0.id,
    p1_0.category_id,
    p1_0.content,
    -- 등등 Post 필드들
  from
    post p1_0
  where
    p1_0.status=?
  order by
    p1_0.created_at desc,
    p1_0.id desc
  fetch
    first ? rows only

-- 2. 각 Post의 Category 조회 (N회 반복)
Hibernate:
  select
    c1_0.id,
    c1_0.created_at,
    -- 등등 Category 필드들
  from
    category c1_0
  where
    c1_0.id=?
Hibernate:
  select
    c1_0.id,
    c1_0.created_at,
    -- 등등 Category 필드들
  from
    category c1_0
  where
    c1_0.id=?
-- 이하 카테고리 개수만큼 반복

@ManyToOne의 기본 전략은 EAGER(즉시 로딩)이지만 JPQL은 연관관계를 무시하고 작성된 SQL을 그대로 실행한다.

즉 JPA는 우선 SELECT p FROM Post p 라는 JPQL을 해석해 post 테이블만 조회하는 SQL을 먼저 날린 후 데이터를 가져와 Post 엔티티를 통해 Category가 EAGER로 설정되어 있는 것을 확인한다.

이후 JPA는 EAGER(즉시 로딩)라고 판단하고 가져온 각 Post에 담긴 category_id를 이용해 category 테이블을 건별로 다시 조회한다. (N+1)

또한 실무에서는 보통 모든 연관관계에 대해 FetchType.LAZY (지연 로딩)를 기본으로 설정하는 것이 관례이자 권장 사항이기 때문에 이를 해결하기 위해서는 연관된 엔티티를 별도의 쿼리가 아닌 한 번의 JOIN 쿼리로 가져오도록 강제해야 한다.

해결 방법  

1) JPQL Fetch Join (명시적 조인)

JOIN FETCH를 사용하여 SQL 레벨에서 조인을 수행한다.
 

@Query("""
      SELECT p FROM Post p
      LEFT JOIN FETCH p.category
      WHERE p.status = :status
      ORDER BY p.createdAt DESC, p.id DESC
      """)
Slice<Post> findPublishedPosts(@Param("status") PostStatus status, Pageable pageable);

* category가 nullable이기 때문에 LEFT JOIN을 선택하였다. 

2) @EntityGraph

JPA에서 제공하는 어노테이션으로 쿼리 로직은 유지하면서 Fetch 전략만 수정한다.
 

@EntityGraph(attributePaths = { "category" })
@Query("""
      SELECT p FROM Post p
      WHERE p.status = :status
      ORDER BY p.createdAt DESC, p.id DESC
      """)
Slice<Post> findPublishedPosts(@Param("status") PostStatus status, Pageable pageable);

두 방법 모두 left join이 포함된 단 한 번의 쿼리로 모든 데이터가 조회된다.

Hibernate:
  select
    p1_0.id,
    c1_0.id,
    c1_0.created_at,
    -- 등등 필드들
  from
    post p1_0
  left join
    category c1_0
      on c1_0.id=p1_0.category_id
  where
    p1_0.status=?
  order by
    p1_0.created_at desc,
    p1_0.id desc

fetch join을 명시적으로 @Query 안에 작성하는 경우 조인 타입과 조건을 명확하게 제어할 수 있다는 점이 장점이지만 현시점에서는 글 목록 조회 쿼리가 복잡하지 않기 때문에 가독성이 좋은 @EntityGraph를 사용하기로 결정하였다. 

추가) DTO Projection

위의 두 가지 방법으로도 해결 가능하지만 엔티티 자체를 조회하는 대신 화면이나 API 응답에 필요한 필드들만 DTO로 직접 조회하는 DTO Projection도 가능하다.

@Query("""
  SELECT new com.example.project.dto.PostResponse(
    p.id,
    p.title,
    c.name
  )
  FROM Post p
  LEFT JOIN p.category c
  WHERE p.status = :status
  """)
Slice<PostResponse> findPublishedPostDtos(
  @Param("status") PostStatus status, Pageable pageable
);

처음부터 필요한 필드만 JOIN해서 가져오므로 N+1이 발생할 여지가 없다. 또한 SELECT * 이 아니라 SELECT p.id, p.title... 처럼 필요한 컬럼만 명시하므로 DB와 애플리케이션 사이의 데이터 전송량이 줄어든다.

다만 JPQL안에 DTO의 전체 패키지 경로를 적어야 해서 가독성이 떨어질 수 있고 조회된 결과가 영속상태(Managed)가 아니므로 데이터를 수정해도 DB에 자동 반영되지 않는다.