[Spring] N+1 Problem

📌  N+1 Problem 이란

연관관계가 설정된 엔티티를 조회할 때, 조회된 데이터 개수(N) 만큼 연관관계의 조회 쿼리가 추가로 발생하는 현상

예를 들어, 블로그 게시글과 댓글이 있는 경우, 게시글을 조회한 후 각 게시글마다 댓글을 조회하기 위한 추가 쿼리가 발생할 수 있다. 이를 N+1 문제라고 한다.

 

---

 

🔸 발생 원인

• JPA와 같은 ORM에서는 연관된 엔티티를 Proxy 객체로 Lazy Loading(지연로딩)을 한다.
  • Proxy 객체 : 실제 객체를 대신하여 사용자의 요청이 있을 때 실제 객체를 생성하여 반환하는 객체
  • Lazy Loading : 연관된 엔티티를 조회하는 시점에 쿼리를 실행하여 조회하는 방식
• Lazy Loading을 하는 이유
  • 불필요한 데이터를 조회하지 않기 위함이다.
  • 1:N 의 연관관계의 경우 많은 데이터를 한 번에 조회하게 되면 DB 성능에 문제가 발생할 수 있다.

 

---

 

🧾 N+1 예시 코드

다음과 같은 Entity 가 있다고 할 때,

@Entity(name = "post")
data class Post (
    @field:Id
    @field:GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long? = null,
    val title: String,
    val content: String,
    val author: String,
    @field:OneToMany(mappedBy = "post", fetch = FetchType.LAZY)
    val comments: List<Comment> = listOf()
)

• Post 는 여러 개의 Commnet를 가지고 있다. (1:N 관계)
• 그리고 Lazy Loading 방식으로 설정
  → Post만 먼저 가져오고, comments 를 꺼낼 때 그제서야 DB에 가서 쿼리를 날림

 

이러면 어떤 문제가 생기냐하면 -

ex1)

/ api / posts / {id} API를 호출하면 PostResponse를 1개 반환하고 이 API를 사용할 때 발생한 쿼리는 다음과 같다.

위 내용을 보면 Post를 조회하기 위한 쿼리가 1번 Comment를 조회하기 위한 쿼리가 1번 발생할 수 있다. (총 2번)
이를 N+1 문제라고 한다.

ex2)

val posts = postRepository.findAll() // Post 엔티티 20개 가져옴
for (post in posts) {
    println(post.comments) // Post마다 comment 조회
}

위 코드처럼 findAll( )로 20개의 Post를 한 번의 쿼리로 모두 가져오면

SELECT * FROM post;

• Post 조회 쿼리 1번
• Comment 조회 쿼리 20번 (Post 하나당 1번씩)
• 총 21번의 쿼리 → 비효율적

 

---

 

🚨 N+1이 왜 문제가 되는가?

🧩 문제 상황 설명 (N+1 문제)

예를 들어 Post가 20개 정도 있고, Comment가 2000개 정도 있다고 가정할 때,
Post를 조회하는 API를 호출하면 20개의 Post를 조회하는 쿼리가 발생하고,
각 Post마다 Comment를 조회하는 쿼리가 20번 발생하게 된다.
이렇게 되면 총 20+1번의 쿼리가 발생하게 되어 DB에 부하가 걸리게 된다.

• Post 20개 존재
• Post를 조회하는 쿼리  : 1번
• 각 Post에 대한 Comment를 조회하는 쿼리 : 20번
• 총 쿼리 수 : 1번 (Post 전체) + 20(각 Post의 Comment) = 21번

 

🧨 문제점

• DB에 많은 부하 유발 : Post 수가 많아질수록 쿼리 수도 비례적으로 증가
• 성능 저하 : 특히 트래픽이 많은 서비스에서 성능 병목의 원인이 된다.
• 비효율적인 데이터 접근 : 동일한 유형의 쿼리를 반복적으로 보내는 비효율 발생

이런 경우, DB의 성능이 충분하다면 단 한번의 조인으로 모든 데이터를 조회하는 것이 효율적이다.

 

❗중요한 포인트는 쿼리 횟수

데이터가 많든 적든, Lazy Loading에서는 Post 수만큼 쿼리가 더 나간다는 점이 N+1 문제의 핵심이다.
필요할 때만 데이터를 조회하려다 보니, 예상보다 많은 쿼리가 발생

 

---

 

✅ 해결 방법

❌ fetchType.EAGER을 사용하면 안된다!

• 단순히 EAGER로 바꾸면 조회 시점에 comment 까지 다 가져오지만,
• 예상치 못한 대량 조회로 오히려 성능 저하나 순환 참조 문제가 생길 수 있다.

    fun findAll(): List<PostResponse> {
        return postRepository.findAll().map{
            logger.info("Comment 조회 전")
            val result = PostConverter.toResponseUseRepository(it)
            logger.info("Comment 조회 후")
            result
        }
    }

현재 Comment가 객체 탐색되는 위 코드에서 toReponseUseRepository 부분이다.
그래서 해당 라인 앞 뒤로 log를 찍어보면 Lazy Loading에서는 아래와 같은 결과가 나온다.

 

반면 EAGER 로 설정하면 아래와 같은 결과가 나온다.

이러한 결과가 나오는 이뉴는 Post N개를 조회하는 상황에서는 Lazy와 Eager의 차이는 Comment가 조회되는 시점에 Comment를 조회하는지(Lazy), Post를 조회하는 시점에 Comment를 조회하는지(Eager)의 차이이기 때문이다.

+) Post 1개를 조회하는 상황에서는 FetchType.EAGER 을 사용하면 N+1 문제가 발생하지 않고 Left Join이 걸린다. (1:1)

 

01 FetchJoin 사용 (JPA 권장 방식)

• fetch join은 연관 관계에 있는 엔티티를 한 번에 즉시 로딩하는 구문
• @Query로 직접 조인해서 한 번에 가져오는 방법

select distinct u
from User u
left join fetch u.posts

@Query Annotation을 사용해서 Fetch Join을 사용하는 방법

    @Query("SELECT p FROM post p JOIN FETCH p.comments")
    fun findAllPostFetchJoinComments(): List<Post>

실제 발생 쿼리는 다음과 같다

Hibernate: select p1_0.id,p1_0.author,c1_0.post_id,c1_0.id,c1_0.author,c1_0.content,p1_0.content,p1_0.title from example.post p1_0 join example.comment c1_0 on p1_0.id=c1_0.post_id

즉, Post + Command를 필요한 시점에 필요한 데이터만 한 번의 쿼리로 가져와 N+1 문제 해결

 

02 Batch Size (지연 로딩 개선)

• Lazy Loading 시 프록시 객체를 조회할 때 where in 절로 묶어서 한 번에 조회할 수 있게 해주는 옵션
• 지연 로딩을 유지하면서, 쿼리를 묶어서 한 번에 가져오는 방식

@OneToMany(mappedBy = "post")
@BatchSize(size = 100)
val comments: List<Comment>

 

• yml 에 전역 옵션으로 적용할 수 있고 @BatchSize 를 통해 연관관계 BatchSize를 다르게 적용 가능

spring:
  jpa:
    properties:
      hibernate:
        default_batch_fetch_size: 100

 

• BatchSize 100 ~ 1000 정도로 적용하고 DBMS에 따라서 where in 절은 1000까지 제한하는 경우가 있으므로 1000 이상은 설정을 잘 하지 않는다.

 

03 EntityGraph 사용

@EntityGraph(attributePaths = {"posts"}, type = EntityGraphType.FETCH)
List<User> findAll();

• JPA에서 제공하는 어노테이션
• 특정 엔티티를 조회할 때 연관된 엔티티도 함께 fetch join 하도록 설정
  즉,
• @EntityGraph Annotation을 사용하면 EntityGraph의 로딩을 기본 Lazy에서 Eager로 변경할 수 있다.
• → 특정 쿼리에 대해서만 EAGER 처럼 작동하게 만들 수 있다.
• EntityGraph를 사용하는 경우 Left Outer Join 으로 Post + Comment 같이 조회하여 데이터를 가져온다.

 

04 그 외 방법들

• MyBatis나 QueryDSL 같은 QueryBuilder를 사용해서도 N+1 문제를 해결할 수 있다.
• 직접 SQL에 가까운 쿼리를 작성해서 N+1 문제를 제어 가능

 

 

🔚 정리

방법	특징	장점	단점
Lazy Loading	필요할 때만 조회	불필요한 조회 방지	N+1 문제 발생 가능
EAGER	처음부터 다 조회	편리하지만 예측 어려움	과도한 조회, 순환 참조 위험
Fetch Join	한 번에 조인해서 조회	성능 매우 좋음	조인으로 인한 중복 가능성
Batch Size	Lazy + 일괄조회	유연하게 쿼리 수 감소	IN절 제한 주의 필요
EntityGraph	쿼리마다 EAGER처럼 작동	유연하고 간편	상황에 따라 복잡해질 수 있음

 

 

reference

https://github.com/jmxx219/CS-Study/blob/main/spring/N%2B1%20Problem.md

CS-Study/spring/N+1 Problem.md at main · jmxx219/CS-Study

https://www.maeil-mail.kr/question/49

매일메일 - 기술 면접 질문 구독 서비스