> For the complete documentation index, see [llms.txt](https://yihyuns-gitbook.gitbook.io/today-i-learned/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yihyuns-gitbook.gitbook.io/today-i-learned/spring/jpa/jpa_fetch_.md).

# JPA의 Fetch 전략

## 정의

* JPA에서 Entity를 조회할 때, 연관 관계를 맺은 다른 엔티티들을 어떻게 가져오는지를 결정하는 전략
* EAGER(즉시), LAZY(지연) 로딩 두 가지 전략이 존재

## EAGER Loading

* 특정 엔티티를 조회할 때 연관 관계를 맺은 다른 엔티티들을 모두 함께 조회
* 조회할 필요가 없는 연관 엔티티도 함께 조회해오는 비효율성 초래 가능
* 그렇다고 해서 무조건 연관 관계를 맺은 엔티티 정보를 사용하는 경우에도 EAGER만 사용하는 것은 좋지 않다. `N+1 문제` 때문
* `@OneToOne`, `@ManyToOne`의 Default 전략 (연관된 것이 단일 컬럼)

## LAZY Loading

* 특정 엔티티 조회 시 연관 관계를 맺은 다른 엔티티들은 `프록시 객체`로 생성
  * 왜 이렇게 하는지 이해하려면, 프록시 패턴을 알고 있으면 좋다.
  * 이유 요약: 연관 관계를 맺은 엔티티는 `필요할 때` 조회해오기 위함
* Entity에서 연관 관계를 맺은 entity instance의 조회 메소드(getter)가 호출되면, 그 시점에 쿼리가 실행됨
* `@OneToMany`, `@ManyToMany`의 Default 전략 (연관된 것이 다중(리스트) 컬럼)

## Fetch 전략은 N+1의 해결과는 연관이 없다!

* EAGER에서는 연관 관계를 맺은 엔티티가 있다면 반드시 N+1(추가 쿼리) 발생
* LAZY에서는 연관 관계를 맺은 엔티티를 조회하지 않는 한 추가 쿼리가 발생하지 않으나, 조회한다면 발생
* 따라서 EAGER로 설정했을 때 N+1이 발생한다고 Fetch 전략을 LAZY로 바꾼 후 N+1이 해결되었다고 단정짓는 것은 위험
  * 추후에 연관 관계를 맺은 Entity의 정보를 사용하게 된다면 어차피 N+1이 발생하게 되기 때문