N+1

정의

• N+1 문제는 [[entity]] 간 관계를 조회할 때 발생하는 성능 이슈.

• N개의 부모 [[entity]]를 조회한 후(1번의 쿼리) 각 부모와 연관된 자식 엔티티를 조회할 때 추가적인 N번의 쿼리가 발생하는 현상

원인

• [[entity]] 간 연관 관계

• 지연 로딩(Lazy Loading)의 동작 방식

  • 지연 로딩은 연관 엔티티를 실제로 사용할 때까지 데이터베이스 조회를 미루는 전략

  • 연관된 데이터를 실제로 사용하는 시점에 각각의 엔티티마다 개별 쿼리가 발생하게됨

예시

일대다(One-to-Many) 관계

@Entity
public class Department {
    @OneToMany(mappedBy = "department", fetch = FetchType.LAZY)
    private List<Employee> employees;
}

• 하나의 Departemnt 에 여러 Employee 가 연결되는 구조 (일대다)

// 1번의 쿼리로 부서 조회
List<Department> departments = entityManager.createQuery(
    "SELECT d FROM Department d", Department.class).getResultList();

// N번의 쿼리 발생 (각 부서마다 직원 조회), 보통 개발자가 의도하지 않은 동작일 가능성이 높다.
for (Department dept : departments) {
    System.out.println(dept.getEmployees().size());
}

다대일(Many-to-One) 관계

@Entity
public class Member {
    @ManyToOne(fetch = FetchType.LAZY)
    private Team team;
}

• 여러 Member가 하나의 팀에 연결된 관계 (다대일)

// 문제가 발생하는 코드
List<Member> members = memberRepository.findAll(); // 1번 쿼리
for (Member member : members) {
    String teamName = member.getTeam().getName(); // N번의 추가 쿼리 발생
}

해결 방법

페치 조인(Fetch Join) 사용

• 한 번의 쿼리로 연관된 엔티티까지 함께 조회

@Query("SELECT t FROM Team t JOIN FETCH t.members")
List<Team> findAllWithMembers();

주의할 점 1 -> 레코드 중복

• member가 3개의 row라면, fetch join 결과 3개의 row가 응답 받는다.

• distinct 옵션이 필요할 수도 있음.

@Query("SELECT DISTINCT t FROM Team t JOIN FETCH t.members")
List<Team> findAllWithMembers();

주의할 점 2 -> in-memory pagination

• 레코드 중복에서 파생되는 이슈

  • member가 3개의 row라면, fetch join 결과 3개의 row가 응답 받는다.

  • 데이터베이스에서 pagination 하기는 불가능.

• 그러므로 모든 record 는 메모리에 올린다음에 중복을 제거한다음 그리고 pagination 을 한 결과를 반환한다.

• fetch join을 그대로 사용할 꺼라면..

  • 아래와 같이 countQuery를 별도로 분리할 필요가 있을듯.

@Query(value = "SELECT t FROM Team t LEFT JOIN t.members",
       countQuery = "SELECT COUNT(DISTINCT t) FROM Team t")
Page<Team> findAllWithMembers(Pageable pageable);```

![image](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*KIK3GwcFSapUEbkx4C0hbw.png)
- fetch join을 그대로 유지할 겅우 위와 같은 warn 로그가 계속 발생한다.
- `fail_on_pagination_over_collection_fetch=true` 옵션을 키는 것을 고려하자
	- 왜?
	- 아예 해당 이슈가 발생할 수 있는 원인을 제거하는게 나을 수도. (메모리 모두 올린다는게..)
	- fetch join을 사용하지 않고, 다른 방법을 선택해야함..

> 주의할 점 3 -> MultipleBagFetchException

- 하나의 쿼리에서 둘 이상의 컬렉션(OneToMany, ManyToMany)을 Fetch Join하려고 할 때 발생하는 예외

```java
@Entity
public class Team {
    @OneToMany(mappedBy = "team")
    private List<Member> members;  // 첫 번째 컬렉션

    @OneToMany(mappedBy = "team")
    private List<Project> projects;  // 두 번째 컬렉션
}

// 예외 발생 쿼리
@Query("SELECT t FROM Team t JOIN FETCH t.members JOIN FETCH t.projects")
List<Team> findAllWithMembersAndProjects();

• 왜 발생할까?

  • 카테시안 곱(Cartesian Product) 문제

    • 한 팀이 3명의 멤버와 2개의 프로젝트를 가지면 총 6개의 row가 생성

  • 데이터 정합성 문제

    • Hibernate는 List 타입의 컬렉션을 Bag

    • Bag은 순서가 없고 중복을 허용하는 자료구조

    • 여러 컬렉션을 조인하면 데이터의 정확성을 보장

• 어떻게 해결할까?

  • Set 사용

    • 데이터 정합성 문제는 풀 수 있다.

    • 여전히 여러 컬렉션의 Fetch Join은 권장되지 않음

  • 개별 쿼리를 사용하거나 -@BatchSize 를 사용해야함.

주의할 점 4 -> alias 이슈

• fetch join은 JPQL의 기능

• JPA 표준에서는 제약이 있다.

  • Alias 사용 불가

  • ON 절을 이용한 필터링 불가

// JPA 표준에서 허용하지 않는 형태, on을 통해 필터링 불가
SELECT t FROM Team t JOIN FETCH t.members m ON m.status = 'ACTIVE'  // ❌ 불가능

• 그렇지만 hibernate 에서는 아래 기능을 지원한다.

// Hibernate에서는 가능하지만 권장되지 않음
SELECT t FROM Team t JOIN FETCH t.members m WHERE m.createdAt < :date  // ⚠️ 위험

@Entity
public class Team {
    @Id
    private Long id;
    
    @OneToMany(mappedBy = "team", cascade = CascadeType.ALL)
    private Set<Agreement> agreements;
}

@Entity
public class Agreement {
    @Id
    private Long id;
    
    @ManyToOne
    private Team team;
    
    private LocalDateTime agreedAt;
}

// 위험한 쿼리 예시
@Query("SELECT t FROM Team t JOIN FETCH t.agreements a WHERE a.agreedAt < :date")
List<Team> findTeamsWithAgreementsBefore(@Param("date") LocalDateTime date);

• findTeamsWithAgreementsBefore를 사용할 때 아래와 같은 문제가 발생할 수 있음.

  • agreements 컬렉션에는 필터링된 데이터만 존재

    • 실제 DB에는 더 많은 Agreement가 있을 수 있음

  • 필터링된 상태에서 컬렉션(agreements) 을 수정하면

    • team.getAgreements().clear()

    • 필터링되지 않은 Agreement도 삭제될 수 있음

  • 중복키 이슈

    • 필터링으로 인해 보이지 않는 Agreement가 있는 상태에서

    • team.getAgreements().add(newAgreement) 이미 존재하는 ID를 가진 Agreement를 추가하는 순간

    • 중복 키 예외 발생한다.

• 그러므로..

  • join fetch에선 항상 연관된 모든 엔티티를 다 끌어오는 것을 기본으로 하는 것이 좋을듯

EntityGraph 사용

• JPA가 제공하는 어노테이션으로, 페치 조인과 유사한 기능

• 단, Entity graph는 left outer join으로만 쿼리가 구성됨.

@EntityGraph(attributePaths = {"members"})
@Query("SELECT t FROM Team t")
List<Team> findAllWithMembersEntityGraph();

@BatchSize 설정

• 지정된 size만큼 IN 절로 한 번에 조회

• hibernate.default_batch_fetch_size 를 통해 전역 설정도 가능.

@Entity  
class User {  
	@BatchSize(size = 20)  
	@OneToMany(mappedBy = "user", fetch = FetchType.EAGER, cascade ={CascadeType.MERGE, CascadeType.PERSIST})  
	val _agreements: MutableSet<UserAgreement> = mutableSetOf();  
	val agreements get() + _agreements.toSet()  
}

• key의 개수가 30개였고 BatchSize로 20을 지정했다면,

  • select ~ from agreements where key in (?1, ?2, …?20)

  • select ~ from agreements where key in (?1, ?2, …?10)

  • 두 번의 추가 쿼리가 발행된다.

• 연관 데이터가 대용량일 때, 메모리 사용량을 고려하면 괜찮은 선택이 될 수 있을듯

DTO 직접 조회

• 필요한 데이터만 직접 조회하는 방법

@Query("SELECT new com.example.TeamDTO(t.id, t.name, m.id, m.name) " +
       "FROM Team t JOIN t.members m")
List<TeamDTO> findAllDTO();

Reference

• https://medium.com/@liberatoreanita/analyze-and-understand-the-n-1-problem-in-hibernate-920cbc056705

• https://www.baeldung.com/spring-hibernate-n1-problem

• https://medium.com/@taesulee93/spring-data-jpa-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C-n-1-query-problem-%EC%9D%98-%EB%8B%A4%EC%96%91%ED%95%9C-%ED%95%B4%EA%B2%B0%EB%B0%A9%EB%B2%95%EA%B3%BC-%EC%9C%A0%EC%9A%A9%ED%95%9C-hibernate-%EC%84%A4%EC%A0%95-%EA%B0%92-3eadd956093e