[SPRING] 🅽 JPA의 N+1문제 해결하기 - JPQL & @EntityGraph

⚡️ N+1 문제

N+1 문제는 무엇이고, 왜 발생할까??

🔍 정의

: N+1 문제는 1번의 쿼리로 N개의 엔티티를 조회한 후, 각 엔티티의 연관된 엔티티를 N번 추가 쿼리로 조회하는 상황!
➡️ LAZY로 엔티티를 만들었을 때 발생함!
(이렇게 말하면 이해가 잘 가지 않으니,,, 예시로 알아보자)

SELECT * FROM todos;
-- Todo를 먼저 가져오고(1번)~ 그다음에 그에 맞는 유저 또 찾아오기(N번) => N+1
SELECT * FROM users WHERE id = 1;
SELECT * FROM users WHERE id = 2;
...

SQL로 보면 조금 더 이해가 간다~!

✅ 왜 지연 로딩(LAZY)에서만 N+1 문제가 발생할까?

🔸 LAZY 로딩이란?
스프링을 실행하자마자 연관된 엔티티를 바로 가져오지 않고,
실제로 내가 "이거 이제 접근해!" 라고 할때 DB에서 가져오는 방식(그때그때 조달)

아래의 코드처럼 설정되어있을 때 실행시에 가져오는게 아니라,
todo.getUser()(유저 가져와!)를 처음 호출할 때!!! 비로소 User 정보를 가져오는 쿼리가 실행된다

@ManyToOne(fetch = FetchType.LAZY)
private User user;

☑️ 예시로 알아보기

아래의 코드는 Todo를 조회하는 코드이다.

public Page<TodoResponse> getTodos(int page, int size) {
        Pageable pageable = PageRequest.of(page - 1, size);

        Page<Todo> todos = todoRepository.findAllByOrderByModifiedAtDesc(pageable);

        return todos.map(todo -> new TodoResponse(
                todo.getId(),
                todo.getTitle(),
                todo.getContents(),
                todo.getWeather(),
                new UserResponse(todo.getUser().getId(), todo.getUser().getEmail()),
                todo.getCreatedAt(),
                todo.getModifiedAt()
        ));
    }

new UserResponse(todo.getUser().getId(), todo.getUser().getEmail()), 여기 코드를 자세히 보자
user도 함께 가져오고 있는 모습을 볼 수 있따!

그러면 Todo 객체를 가져올떄 user는 조회되지 않은 상태였기 때문에(User는 아직 로딩x), map() 안에서 접근할 때마다 N개의 쿼리가 날아가게 된다,,,🥹

이를 방지하기 위해서 JPQL을 활용하면 된다!!!
두가지 방법을 사용할 수 있다 ➡️ @Query & @EntityGraph

---

💓 JPQL 활용하기!

JPQL이 뭘까?

약간 JPQ + SQL구문으로 생각하면 편할 것 같다!

📌 JPQL (Java Persistence Query Language)
JPA에서 SQL처럼 쓰는 "객체 지향 쿼리 언어"

여기서 SQL과 약간 다른점은,
SQL → 테이블 기준으로 질의
JPQL → 엔티티 기준으로 질의

자 이제 @Query & @EntityGraph를 사용해서 개선해보자!

💡 @Query

MVC 구조에서 Repository에서 DB를 조회할때 활용할 수 있는데,
예시 코드로 알아보자

@Query("SELECT t FROM Todo t LEFT JOIN FETCH t.user u ORDER BY t.modifiedAt DESC")

Page<Todo> findAllByOrderByModifiedAtDesc(Pageable pageable);

@Query("SELECT t FROM Todo t " +
       "LEFT JOIN FETCH t.user " + --> 여기
       "WHERE t.id = :todoId")
Optional<Todo> findByIdWithUser(@Param("todoId") Long todoId);

여기서 LEFT JOIN FETCH t.user는 바로 N+1 문제 해결을 위한 fetch join!
➡️ 즉, Todo를 조회하면서 각 Todo에 연결된 User도 한 번에 같이 로딩!!!

sql 관점에서는 두 테이블을 조인시켜서 가져오는 것과 비슷하다! => 한번에 조회

SELECT t.*, u.* 
FROM todos t
JOIN users u ON t.user_id = u.id;

SELECT t FROM Todo t는 실제로는 todos 테이블이지만,
JPQL에서는 Todo라는 엔티티 클래스를 기준으로 쿼리 짜는 것!

📌 @EntityGraph로 개선해보기

📌 @EntityGraph란?
LAZY설정된 연관 엔티티를 한 번에 같이 로딩(Eager처럼!)하고 싶을 때 사용하는 JPA의 어노테이션
👉 JPQL의 fetch join과 똑같은 기능을 선언적으로 처리해줌!

아까 코드를 JPA의 @EntityGraph로 개선해보자!

    @EntityGraph(attributePaths = "user")
    Page<Todo> findAllByOrderByModifiedAtDesc(Pageable pageable);

    @EntityGraph(attributePaths = {"user"})
    Optional<Todo> findById(@Param("todoId") Long todoId);

아까 길었던 코드를 이렇게 짧게 줄일 수 있다!

물론 두개를 함께 사용하는 것도 가능하다

⚡️ JPQL + @EntityGraph 조합
만약 조건이 복잡해서(내림차순, 여러가지 조건들,,) @Query를 써야 한다면, 이렇게도 가능!

@EntityGraph(attributePaths = {"user"})
@Query("SELECT t FROM Todo t ORDER BY t.modifiedAt DESC")
List<Todo> findAllWithUserOrderByModifiedAt();

이 경우에도 @EntityGraph가 작동해서 t.user를 같이 fetch!

🛒 정리

상황에 맞춰서, 어떤 방식이 더 올바를지 보고 선택하면 된다.

비교	JPQL → 'fetch join'	JPA → '@EntityGraph'
선언 방식	쿼리 직접 작성	어노테이션
유지보수	길어질 수 있음	깔끔하고 재사용 쉬움
기능	완전한 제어 가능	선언적, 간단함
장점	복잡한 조건 가능	코드 간결