프록시와 연관관계 관리 - 즉시 로딩과 지연 로딩

Member를 조회할 때 Team도 함께 조회해야 할까?

단순히 member 정보만 사용하는 비지니스 로직이라면 Team을 JOIN해서 조회하는 것은 손해다.

그래서 JPA는 지연로딩이라는 기능을 제공한다.

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn
private Team team;

이렇게 @ManyToOne에 fetch = FetchType.LAZY를 추가하면 프록시 객체로 가져옵니다. 

println(member.getName());

 

지연 로딩 LAZY을 사용해서 프록시로 조회

Team에 있는 값을 실제로 사용하는 시점에 DB 쿼리를 날린다.

 

Member와 Team을 자주 함께 사용한다면

 

즉시 로딩 EAGER를 사용해서 함께 조회

@Entity
public class Member {
	@Id
	@GeneratedValue
	private Long id;
	
   	@Column(name = "USERNAME")
	private String name;
		
	@ManyToOne(fetch = FetchType.EAGER) //**
	@JoinColumn(name = "TEAM_ID")
	private Team team;
	..
}

 

즉시 로딩

즉시 로딩(EAGER), Member 조회시 항상 Team도 조회

 

프록시와 즉시로딩 주의

• 가급적 지연 로딩만 사용(특히 실무에서)
• 즉시 로딩을 적용하면 예상하지 못한 SQL이 발생
• 즉시 로딩은 JPQL에서 N + 1 문제를 일으킨다.
  • em.find는 pk를 찍어서 가져오기 때문에 jpa가 내부적으로 최적화 할 수 있다.
  • 하지만, jpql의 경우에는 jpql이 sql로 번역되고 번역된 sql을 실행한 후
    fetch type이 즉시 로딩인 경우 sql 대상 엔티티의 수만큼 쿼리를 발생시킨다.
    즉, jpql 먼저 실행한 후에 즉시 로딩 대상이 있다면 쿼리를 한번 더 보낸다.
• @ManyToOne, @OneToOne은 기본이 즉시 로딩 -> LAZY로 설정
• @OneToMany, @ManyToMany는 기본이 지연 로딩

실무에서는 모든 연관관계를 지연로딩으로 전부 설정하고
1. fetch join : 동적으로 함께 join할 연관관계를 정할 수 있다.
2. 어노테이션
3. 배치 사이즈 : 1 + 1

 

지연 로딩 활용(이론)

• Member와 Team은 자주 함께 사용 -> 즉시 로딩
• Member와 Order는 가끔 사용 -> 지연 로딩
• Order와 Product는 자주 함께 사용 -> 즉시 로딩

 

 

지연 로딩 활용(실무)

• 모든 연관관계에 지연 로딩을 사용해라!
• 실무에서 즉시 로딩을 사용하지 마라!
• JPQL fetch 조인이나, 엔티티 그래프 기능을 사용해라!
• 즉시 로딩은 상상하지 못한 쿼리가 나간다.