N + 1 문제와 해결 방법 Fetch Join, Batch Size, Entity Graph

DB에서 정말 빈번하게 발생하는 N + 1문제를 인식하고 (드디어) 이해를 해서 포스팅을 해보려고 한다.

 

N + 1 문제란 ?

ORM (Object Relational Mapping)을 사용할 때 발생할 수 있는 비효율적인 데이터베이스 쿼리 문제를 말한다.

연관관계에 있는 엔티티에서 하나의 엔티티를 조회할 때 관련된 엔티티를 조회하기 위해 추가적인 쿼리가 반복적으로 실행되는 상황을 말한다.

 

연관관계 (1 : N, N : 1) 의 엔티티를 조회할 때 조회된 데이터 갯수 (n) 만큼 연관관계의 조회 쿼리가 추가로 발생하여 데이터를 읽어오게 된다. 즉, 1번의 쿼리를 날렸을 때 의도하지 않은 N번의 쿼리가 추가적으로 실행되는 것이다.

 

처음에 오해한 생각 : 

  내가 로그인이 필요한 모든 메소드에서 MemberAdapter를 파라미터로 받아 Member 엔티티를 추출해서 각 메소드의 역할에 맞게 로그인 한 사용자를 사용하는데 나는 이게 Member 만큼 조회를 진행하거나 하니까 N + 1 문제인 줄 알았다 ;; 

예를 들어 아래 같은 경우에..

public boolean createCategory(
            final MemberAdapter memberAdapter, final CreateCategoryRequest request) {

        Member member = getMemberByMemberAdapter(memberAdapter);

        scheduleCategoryRepository.findByCategoryNameAndMember(request.getName(), member)
                .ifPresent(scheduleCategory -> {
                    throw new ScheduleException(ErrorCode.DUPLICATED_CATEGORY_NAME);
                });

        scheduleCategoryRepository.save(request.toEntity(member));

        return true;
    }
  private Member getMemberByEmail(String email) {
        return memberRepository.findByEmail(email)
                .orElseThrow(() -> new MemberException(ErrorCode.MEMBER_NOT_FOUND));
    }

    public Member getMemberByMemberAdapter(final MemberAdapter memberAdapter) {

        return getMemberByEmail(memberAdapter.getUsername());
    }

 

하지만 

N + 1 문제는 연관관계가 있는 엔티티들에 의해 의도하지 않은 추가 쿼리가 반복적으로 발생하는 경우이다 .

 

위와 같은 경우는 Member 엔티티 조회 후 추가 작업을 진행하는 것일 뿐이며 로직은 다음과 같다.

 

1. Member 조회 로직

2. 조회한 멤버를 바탕으로 scheduleCategory 조회 쿼리

3. save 쿼리 

 

=> 이렇게 쿼리 횟수가 고정적이며 반복적이지 않음. 따라서 N + 1문제는 발생하지 않는다.

 

또 너무 이해가 안 됐던 게 

내 코드에서 레포지토리를 통한 조회로 각각의 필요한 값들을 조회하고 있었다.

List<Long> userPetSchedules =
                petRepository.findPetIdsByMember(member.getMemberId())
                        .stream()
                        .flatMap(petId -> petScheduleRepository.findScheduleIdByPet(petId).stream())
                        .toList();

지피티가 다음과 같은 경우에 N + 1 문제가 발생할 수 있다고 하였는데 그 이유는

 

1. findPetIdsByMember() : member를 통해 petId를 조회하는 쿼리 1번 발생.

2. 각각의 Pet에 일정을 조회하는 쿼리  Pet 수 N번 만큼 발생.

 

Pet이 3마리 일경우 1 + 3 = 4번의 쿼리.

Pet이 100마리 일 경우 1 + 100 = 101번의 쿼리.

 

라고 하는데 당연히 필요해서 조회를 한 거고 이게 반려동물 N만큼 쿼리가 발생하는 건 당연한 건데 왜 문제라고 하는지?? 가 너무너무 이해가 안 됐다.

 

다시 개념을 짚어보자.

N+1 문제가 발생할 수 있는 상황
연관관계가 설정된 엔티티를 조회할 때 조회된 데이터 n개만큼 연관관계의 조회쿼리가 추가로 발생하는 상황
== 1번의 쿼리를 날렸을 때 N번의 의도치 않는 쿼리가 추가적으로 실행되는 상황

 

 

위랑 비슷한 말이라서 역시나 이해가 안 됐고 예제를 만들어봄으로써 이해를 했다.

(Schedule엔티티와 SelectDate는 1 : N 관계이다.)

 public ResponseEntity<?> test(@AuthenticationPrincipal MemberAdapter memberAdapter) {
        List<Schedule> scheduleList = scheduleRepository.findAll();
        for (Schedule schedule : scheduleList) {
            System.out.println("schedule : " + schedule + "selectedDates : " + schedule.getSelectedDates());
        }
        return null;
    }

이 코드를 실행시키면 N + 1문제가 발생한다.

 

scheduleRepository.findAll()로 schedule 엔티티들을 조회해왔고 (조회쿼리 1번)

아래 for문으로 이 엔티티의 selectedDates 필드를 가져오려고 한 것인데 아래와 같이 selectedDates를 각각 조회하는 쿼리가 실행된 것을 알 수 있다.

바로 이것이다 !

나의 의도는 schedule 엔티티만 조회하고 해당 엔티티의 selectDate필드를 가져오려고 했는데 연관관계에 있는 selectDate까지 의도치 않게 조회되는 현상 !

(FetchType.Lazy 로 설정되어 있어 연관관계에 있는 엔티티는 실제 사용할 때 가져오게 되어서 발생한다.)

이게 바로 N + 1문제이다.

 

List<Long> userPetSchedules =
                petRepository.findPetIdsByMember(member.getMemberId())
                        .stream()
                        .flatMap(petId -> petScheduleRepository.findScheduleIdByPet(petId).stream())
                        .toList();

 

그럼 다시 아까 위의 코드로 봤을 때 member로 PetId를 찾아오는 findPetIdsByMember 조회쿼리 1번을 날리고

petId의 갯수만큼 findScheduleIdByPet으로 petSchedule 엔티티를 찾아오게 된다. 

여기서 petSchedule엔티티와 schedule엔티티가 N : 1 연관관계가 설정되어 있으므로 schedule엔티티가 함께 조회되는 

N + 1문제를 일으킬 가능성이 있다.

(여기서 pet의 갯수에 따라 조회 쿼리가 증가하는 건 비효율적인 쿼리문제로 N + 1문제가 아님.)

 

처음엔 @Query어노테이션을 붙여 JPQL을 이용해 정확히 schedule의 id 필드만 가져오도록 작성해보았다.

N + 1 가능성은 모르는 채로 scheduleId만 하나로 모으기 위해서 사용한 것이었는데 결과적으로는 N + 1문제를 방지할 수 있게 되었다.

schedule을 추가로 조회하지 않은 것을 확인했다 !

 

 

만약 JPQL을 통해 작성하지 않고 레포지토리의 메소드를 직접 이용하면 N + 1문제가 발생할 가능성이 여러군데 있다. 

 

다음과 같은 상황에서 member 엔티티로 PetRepository에서 Pet엔티티를 찾아오고 해당 Pet으로 PetSchedule 엔티티에서 PetSchedule 엔티티를 가져오게 되는데 

 

아래 조회 쿼리문을 보면 의도치않게 species 엔티티도 함께 조회가 된 것을 알 수 있다.

 

또한 petScheduleList의 getSchedule()을 하면 schedule 엔티티까지 의도치 않게 조회가 된다. 

(Lazy Loading으로 getSchedule() 실행 시 PetSchedule 갯수만큼 Schedule 조회를 위해 추가 쿼리가 실행되는 상황.)

 

 

이렇게 .. N + 1 이해는 되었다 ..!

---

추가 의문

  계속 찾아보니까 설명들이 지연로딩에 의해 발생한다고 하는데 그럼 FetchType.EAGER(즉시로딩)로 하면 괜찮아질까 ?

 

ㄴㄴ 그럼 초기 1번째 조회 쿼리 때 연관된 엔티티를 불러온다.

 @OneToMany(mappedBy = "schedule", fetch = FetchType.EAGER, cascade = CascadeType.ALL, orphanRemoval = true)
    private List<SelectDate> selectedDates;

 

지연로딩과 즉시로딩은 연관관계의 엔티티를 어느 시점에 불러올 지의 차이라고 알고있다.

 

즉시로딩일 경우

  1. JPQL에서 만든 SQL을 통해 데이터 조회

  2. 이후 JPA에서 Fetch 전략을 가지고 해당 데이터의 연관관계인 엔티티들을 추가 조회

  3. 2번에서 N + 1 발생

 

지연로딩일 경우

  1. JPQL에서 만든 SQL을 통해 데이터 조회

  2. JPA에서 Fetch 전략이 지연로딩이므로 추가 조회 x

  3. 하위 엔티티에 작업시 추가 조회 발생 ->  N + 1문제 발생

 

FetchType.LAZY(지연로딩)이든 즉시로딩이든 시점의 차이이지 N + 1이 발생할 코드(연관관계가 있는 조회쿼리)이면 발생한다. 

 

FetchType.LAZY로 설정 시 연관관계 엔티티를 프록시 객체(가짜객체)로 바인딩 한다.

프록시 객체란 ?) 실제 엔티티 객체를 대신하는 가짜 객체. 지연로딩을 구현하기 위해 사용되며
                             DB에서 데이터를 실제로 가져오는 시점을 늦춰 메모리 사용량을 줄이고 성능을 향상 시킴.

프록시 객체의 동작) 
   1. 엔티티 조회 : 엔티티 조회 시 실제 엔티티 대신 프록시 객체가 반환.
   2. 프록시 사용 : 프록시 객체의 속성에 접근하려고 하면 JPA는 실제 DB에 쿼리를 날려 데이터를 가져와 프록시 객체에 채워 넣음.

 

왜 발생하는가 ?

JpaRepository에 정의한 인터페이스 메소드를 실행하면 JPA가 메소드 이름을 분석해서 JPQL을 생성하여 실행한다.

 

JPQL ? ) SQL을 추상화한 객체지향 쿼리 언어로서 특정 SQL에 종속되지 않고 엔티티 객체와 필드 이름을 가지고 쿼리를 실행.

 

따라서 JPQL은 findAll()을 수행하면 select * from schedule 쿼리만 실행한다. (처음 예시의 경우)

JPQL은 연관관계 데이터를 무시하고 해당 엔티티 기준으로 조회하기 떄문이다.

 

연관 데이터가 필요하면 FetchType으로 지정한 시점에 조회 쿼리를 별도로 호출하게 된다.

 

-----------

그렇다면 어떻게 해결하면 좋을까 ??

N + 1이 발생하는 이유는 연관된 엔티티들을 각각 별개의 쿼리로 조회해오기 때문이다.

그럼 이것을 필요할 때 한 번에 조회해오면 된다는 뜻이다.

 

해결 방법으로는 JPQL을 이용한 Fetch Join과 Entity Graph, Batch size가 있다.

 

1. Fetch Join

두 테이블을 JOIN 하여 한 번에 관련된 모든 데이터를 가져온다.

 

JPQL에서 성능 최적화를 위해 기존의 SQL 조인 종류가 아닌 join fetch를 제공한다.

 

* join fetch는 지연로딩으로 설정해도 우선순위를 가져 즉시로딩으로 동작하게 된다.

  -> 이유 ? ) 당연하게도 FetchType.LAZY로 설정되어있는 연관관계의 엔티티를 사용하려고 할 때 의도치않게 조회해오는 과정을 없애기위해 join fetch를 쓰는 것이기 때문에 !

 

join fetch를 사용하면 JPA&Hibernate가 지연 로딩(Lazy Loading)을 피하기 위해 연관된 엔티티를 즉시 로딩(Eager Fetching)하도록 SQL JOIN 쿼리를 생성한다.

 

 

위의 코드는 member의 id로 아래 레포지토리에 JPQL로 작성해놓은 메소드를 거쳐(fetch join 미적용) Schedule 엔티티들을 가져온다.

    @Query("select s from Schedule s" +
            " join PetSchedule ps ON s.scheduleId = ps.schedule.scheduleId" +
            " join Pet p ON p.petId = ps.pet.petId" +
            " join CareGiver cg ON cg.pet.petId = p.petId" +
            " where cg.member.memberId = :memberId")
    List<Schedule> findByAllSchedule(@Param("memberId") Long memberId);

 

 

그리고 N + 1문제가 발생할 수 있는 상황은 schedule.getPetSchedules()를 할 때 데이터를 가져오기 위한 추가 쿼리 실행.

위 작업이 반복되면서 N + 1문제 발생한다.

 

위 API를 접근하면 발생하는 쿼리문이다.

------start-------------------------------
Hibernate: /* select s from Schedule s join PetSchedule ps ON s.scheduleId = ps.schedule.scheduleId join Pet p ON p.petId = ps.pet.petId join CareGiver cg ON cg.pet.petId = p.petId where cg.member.memberId = :memberId */ select s1_0.schedule_id,s1_0.created_at,s1_0.is_all_day,s1_0.member_id,s1_0.notice_at,s1_0.notice_yn,s1_0.priority,s1_0.repeat_yn,s1_0.category_id,s1_0.schedule_content,s1_0.schedule_time,s1_0.schedule_title,s1_0.updated_at from schedule s1_0 join petschedule ps1_0 on s1_0.schedule_id=ps1_0.schedule_id join pet p1_0 on p1_0.pet_id=ps1_0.pet_id join caregiver cg1_0 on cg1_0.pet_id=p1_0.pet_id where cg1_0.member_id=?
Hibernate: select m1_0.member_id,m1_0.created_at,m1_0.email,m1_0.image,m1_0.name,m1_0.password,m1_0.phone,m1_0.status,m1_0.updated_at from member m1_0 where m1_0.member_id=?
Hibernate: select rp1_0.repeat_pattern_id,rp1_0.end_date,rp1_0.frequency,rp1_0.repeat_interval,s1_0.schedule_id,s1_0.created_at,s1_0.is_all_day,m1_0.member_id,m1_0.created_at,m1_0.email,m1_0.image,m1_0.name,m1_0.password,m1_0.phone,m1_0.status,m1_0.updated_at,s1_0.notice_at,s1_0.notice_yn,s1_0.priority,s1_0.repeat_yn,sc1_0.category_id,sc1_0.category_name,sc1_0.member_id,s1_0.schedule_content,s1_0.schedule_time,s1_0.schedule_title,s1_0.updated_at,rp1_0.start_date from repeatpattern rp1_0 left join schedule s1_0 on s1_0.schedule_id=rp1_0.schedule_id left join member m1_0 on m1_0.member_id=s1_0.member_id left join schedulecategory sc1_0 on sc1_0.category_id=s1_0.category_id where rp1_0.schedule_id=?
Hibernate: select ps1_0.schedule_id,ps1_0.pet_schedule_id,p1_0.pet_id,p1_0.breed_id,p1_0.created_at,m1_0.member_id,m1_0.created_at,m1_0.email,m1_0.image,m1_0.name,m1_0.password,m1_0.phone,m1_0.status,m1_0.updated_at,p1_0.memo,p1_0.pet_age,p1_0.pet_gender,p1_0.pet_image,p1_0.pet_name,s1_0.species_id,s1_0.species_name,p1_0.status,p1_0.updated_at from petschedule ps1_0 left join pet p1_0 on p1_0.pet_id=ps1_0.pet_id left join member m1_0 on m1_0.member_id=p1_0.member_id left join species s1_0 on s1_0.species_id=p1_0.species_id where ps1_0.schedule_id=?
ooo
Hibernate: select ps1_0.schedule_id,ps1_0.pet_schedule_id,p1_0.pet_id,p1_0.breed_id,p1_0.created_at,m1_0.member_id,m1_0.created_at,m1_0.email,m1_0.image,m1_0.name,m1_0.password,m1_0.phone,m1_0.status,m1_0.updated_at,p1_0.memo,p1_0.pet_age,p1_0.pet_gender,p1_0.pet_image,p1_0.pet_name,s1_0.species_id,s1_0.species_name,p1_0.status,p1_0.updated_at from petschedule ps1_0 left join pet p1_0 on p1_0.pet_id=ps1_0.pet_id left join member m1_0 on m1_0.member_id=p1_0.member_id left join species s1_0 on s1_0.species_id=p1_0.species_id where ps1_0.schedule_id=?
ooo
------end-------------------------------

 

한 작업씩 살펴보면 

 

1. JPQL 실행

Hibernate: /* 
  select s 
  from Schedule s 
  join PetSchedule ps ON s.scheduleId = ps.schedule.scheduleId 
  join Pet p ON p.petId = ps.pet.petId 
  join CareGiver cg ON cg.pet.petId = p.petId 
  where cg.member.memberId = :memberId */ 
  
  select s1_0.schedule_id,s1_0.created_at,s1_0.is_all_day,s1_0.member_id,s1_0.notice_at,s1_0.notice_yn,s1_0.priority,s1_0.repeat_yn,s1_0.category_id,s1_0.schedule_content,s1_0.schedule_time,s1_0.schedule_title,s1_0.updated_at 
  from schedule s1_0 
  join petschedule ps1_0 on s1_0.schedule_id=ps1_0.schedule_id 
  join pet p1_0 on p1_0.pet_id=ps1_0.pet_id 
  join caregiver cg1_0 on cg1_0.pet_id=p1_0.pet_id 
  where cg1_0.member_id=?

Schedule 엔티티 리스트를 가져오기 위한 쿼리로 레포지토리 메소드에 @Query로 작성한 sql 구문이다.

 List<Schedule>에 담긴다.

 

2. 연관 엔티티 로딩

Hibernate: 
  select ps1_0.schedule_id,ps1_0.pet_schedule_id,p1_0.pet_id,p1_0.breed_id,p1_0.created_at,m1_0.member_id,m1_0.created_at,m1_0.email,m1_0.image,m1_0.name,m1_0.password,m1_0.phone,m1_0.status,m1_0.updated_at,p1_0.memo,p1_0.pet_age,p1_0.pet_gender,p1_0.pet_image,p1_0.pet_name,s1_0.species_id,s1_0.species_name,p1_0.status,p1_0.updated_at 
  from petschedule ps1_0 
  left join pet p1_0 on p1_0.pet_id=ps1_0.pet_id 
  left join member m1_0 on m1_0.member_id=p1_0.member_id 
  left join species s1_0 on s1_0.species_id=p1_0.species_id 
  where ps1_0.schedule_id=?

 for문으로 ScheduleList의 각 Schedule 엔티티에 대해 schedule.getPetSchedules() 호출 시마다 추가 쿼리 실행.

이 쿼리가 반복적으로 실행되면서 각 Schedule 의 연관 엔티티인 PetSchedule 과 Pet 정보를 가져온다.

 

Schedule 엔티티 리스트를 가져오는 첫 번째 쿼리는 한 번만 실행되지만,

 Schedule 엔티티에 대해 PetSchedule 및 Pet 데이터를 로딩할 때, 추가 쿼리가 반복적으로 실행된다.

 

위 문제를 해결하기 위해 fetch join 사용을 해봤다 !

@Query("select distinct s from Schedule s" +
            " join fetch s.petSchedules ps" +
            " join fetch ps.pet p" +
            " join fetch p.careGivers cg" +
            " where cg.member.memberId = :memberId")
    List<Schedule> findByAllSchedule(@Param("memberId") Long memberId);

 

그런데 다음과 같은 오류가 났다.

2025-01-10T02:12:43.957+09:00 ERROR 26308 --- [nio-8080-exec-4] c.s.P.exception.GlobalExceptionHandler   : org.springframework.dao.InvalidDataAccessApiUsageException : org.hibernate.loader.MultipleBagFetchException: cannot simultaneously fetch multiple bags: [com.sj.Petory.domain.pet.entity.Pet.careGivers, com.sj.Petory.domain.schedule.entity.Schedule.petSchedules]

 

이유를 알아보니까 fetch join은 둘 이상의 컬렉션을 조회할 수 없단다.

이는 fetch join의 한계로 Hibernate는 기본적으로 컬렉션 타입 관계 (@OneToMany 나 @ManyToOne)를 fetch join 할 때 중복 데이터 처리를 위해 List 대신 Set을 사용하는 것을 권장한다.

 

따라서 List 타입 컬렉션을 동시에 fetch join 하면 데이터 정규화를 처리하지 못해 MultipleBagFetchException오류가 발생한다.

 

Set 타입으로 바꾼다고 해도 둘 이상의 컬렉션을 조회하게 되면 데이터 정합성에 문제가 발생하게 된다....

 Y?) 각 컬렉션의 요소가 데카르트의 곱 형태로 쿼리 결과에 포함되기 때문이당..

 

Fetch Join의 한계점

1. 1:N 관계가  두 개 이상의 경우(두 개 이상의 엔티티들을 fetch join 하려고 할 때) 사용불가
2. 패치 조인 대상에 별칭(as) 부여 불가
3. 페이징 사용 불가

 

2. @EntityGraph

EntityGraph는 JPA에서 적용하는 어노테이션으로 특정 메소드에서만 Eager Loading을 적용할수 있다. 

JPQL 쿼리를 작성하지 않고도 연관된 엔티티를 함께 로딩할 수 있도록 설정하는 기능.

 기본 Fetch 전략을 덮어쓰는 방식으로 동작.

 

 

 

3. BatchSize

BatchSize는 연관엔티티를 조회할 때 지정된 size만큼 SQL의 IN 절을 사용하여 조회한다.

@BatchSize를 이용하면 Lazy loading을 사용할 때 연관된 엔티티를 한 번에 가져올 수 있도록 최대 조회 크기 (batch size)를 지정한다. 기본적으로 JPA는 연관 컬렉션이나 엔티티를 하나씩 조회하는데, 이 경우 N + 1 문제가 발생한다.

@BatchSize를 설정하면 여러 엔티티를 한꺼번에 로드하는 방식으로 효율성을 높인다.

 

 

application.yml에 다음과 같이 작성하여도 되고 

  * 이경우 모든 lazy 로딩 관계에 글로벌하게 적용되므로 신중하게 설정해야 함.

spring:
  jpa:
    properties:
      hibernate:
        default_batch_fetch_size: 1000

 

@OneToMany 연관관계를 갖는 엔티티 필드에(개별 엔티티에도 적용가능) @BatchSize 어노테이션을 붙여줘도 된다.

 

적용하고 실행시키면 size 만큼 컬렉션을 묶어서 로딩한다.

아래 쿼리문을 확인해보면  IN절을 사용하여 조회하게 된다.

------start-------------------------------
Hibernate: /* select s from Schedule s join PetSchedule ps ON s.scheduleId = ps.schedule.scheduleId join Pet p ON p.petId = ps.pet.petId join CareGiver cg ON cg.pet.petId = p.petId where cg.member.memberId = :memberId */ select s1_0.schedule_id,s1_0.created_at,s1_0.is_all_day,s1_0.member_id,s1_0.notice_at,s1_0.notice_yn,s1_0.priority,s1_0.repeat_yn,s1_0.category_id,s1_0.schedule_content,s1_0.schedule_time,s1_0.schedule_title,s1_0.updated_at from schedule s1_0 join petschedule ps1_0 on s1_0.schedule_id=ps1_0.schedule_id join pet p1_0 on p1_0.pet_id=ps1_0.pet_id join caregiver cg1_0 on cg1_0.pet_id=p1_0.pet_id where cg1_0.member_id=?
Hibernate: select rp1_0.repeat_pattern_id,rp1_0.end_date,rp1_0.frequency,rp1_0.repeat_interval,s1_0.schedule_id,s1_0.created_at,s1_0.is_all_day,m1_0.member_id,m1_0.created_at,m1_0.email,m1_0.image,m1_0.name,m1_0.password,m1_0.phone,m1_0.status,m1_0.updated_at,s1_0.notice_at,s1_0.notice_yn,s1_0.priority,s1_0.repeat_yn,sc1_0.category_id,sc1_0.category_name,sc1_0.member_id,s1_0.schedule_content,s1_0.schedule_time,s1_0.schedule_title,s1_0.updated_at,rp1_0.start_date from repeatpattern rp1_0 left join schedule s1_0 on s1_0.schedule_id=rp1_0.schedule_id left join member m1_0 on m1_0.member_id=s1_0.member_id left join schedulecategory sc1_0 on sc1_0.category_id=s1_0.category_id where rp1_0.schedule_id=?
Hibernate: select ps1_0.schedule_id,ps1_0.pet_schedule_id,p1_0.pet_id,p1_0.breed_id,p1_0.created_at,m1_0.member_id,m1_0.created_at,m1_0.email,m1_0.image,m1_0.name,m1_0.password,m1_0.phone,m1_0.status,m1_0.updated_at,p1_0.memo,p1_0.pet_age,p1_0.pet_gender,p1_0.pet_image,p1_0.pet_name,s1_0.species_id,s1_0.species_name,p1_0.status,p1_0.updated_at from petschedule ps1_0 left join pet p1_0 on p1_0.pet_id=ps1_0.pet_id left join member m1_0 on m1_0.member_id=p1_0.member_id left join species s1_0 on s1_0.species_id=p1_0.species_id where ps1_0.schedule_id in (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
ooo
ooo
------end-------------------------------

 

 

BatchSize 사용 시 주의할 점

1. 배치 크기를 너무 작게 설정하면 쿼리가 많이 실행돼 성능 저하
                    너무 크게 설정하면 메모리 사용량이 증가 
2. 결과 데이터가 많아질 경우 데이터를 정렬하거나, 처리가 필요한데 @BatchSize로 해결할 수 없다. 
3. Lazy Loading 에서만 동작하므로 FetchType.LAZY로 설정해야 함.

 

이렇게 일단은 Batch Size를 사용해서 작성해보았는데 더 최적화를 하기 위해서 고민을 해봐야할 것 같다.

일단 N + 1 문제가 발생할 수 있는 부분은 해결하였다 ! 

 

정리

N + 1은 JPA 레포지토리를 활용해 인터페이스 메소드를 호출할 때 발생.

N : 1, 1 : N 연관관계를 가진 엔티티를 조회할 때 발생.

주로 지연로딩 설정에 의해 발생한다고 하지만 즉시로딩이어도 발생 ! ( 발생 시점의 차이만 있을 뿐)

해결 방법에는 Fetch Join, Entity Graph, Batch Size 설정이 있음. 

 

 

 

---

참고

https://jh2021.tistory.com/21

JPA n+1 문제는 왜 생기는걸까?

 

https://s-y-130.tistory.com/184

[JPA] N+1 문제 원인 및 해결방법

 

https://programmer93.tistory.com/83#google_vignette

JPA N+1 문제 해결 방법 및 실무 적용 팁 - 삽질중인 개발자