[JPA] 17. JPQL - 2편

자바 ORM 표준 JPA 프로그래밍

 

 

 

 

 

 

 

이 포스팅에서 작성하는 내용은 자바 ORM 표준 JPA 프로그래밍 (김영한 지음) 에서 발췌하였습니다.

 

 

 

1. 경로 표현식

• .(점)을 찍어 객체 그래프를 탐색하는 것

SELECT 	m.username  // 상태 필드
FROM	Member m
 JOIN   m.team t  	// 단일 값 연관 필드
 JOIN   m.orders o	// 컬렉션 값 연관 필드
WHERE 	t.name = 'TEAM_A'

• 상태 필드(state field): 단순히 값을 저장하기 위한 필드(ex : m.username)
• 연관 필드(association field): 연관관계를 위한 필드
  • 단일 값 연관 필드: @ManyToOne, @OneToOne, 대상이 엔티티(ex: m.team)
  • 컬렉션 값 연관 필드: @OneToMany, @ManyToMany, 대상이 컬렉션(ex: m.orders)
• 특징
  • 상태 필드(state field): 경로 탐색의 끝, 탐색X
  • 단일 값 연관 경로: 묵시적 내부 조인(inner join) 발생, 탐색O
  • 컬렉션 값 연관 경로: 묵시적 내부 조인(inner join) 발생, 탐색X → FROM 절에서 명시적 조인을 통해 별칭을 얻으면 별칭을 통해 탐색 가능
• 명시적 조인, 묵시적 조인
  • 명시적 조인 : Join 키워드를 직접 사용해서 명시적으로 조인할 대상을 지정하는 것                                  ex) select m from Member m join m.team t
  • 묵시적 조인 : 경로 표현식에 의해 묵시적으로 SQL 조인이 발생하는 것(내부 조인만 가능)                            ex) select m.team from Member m
• 경로 탐색을 사용한 묵시적 조인 시 주의사항
  • 항상 내부조인이 발생함
  • 컬렉션은 경로 탐색의 끝. 탐색을 더 원한다면 명시적 조인을 통해 별칭을 얻어야 한다.
  • 경로 탐색은 주로 SELECT, WHERE  절에서 사용하지만 묵시적 조인으로 인해 SQL의 FROM (JOIN) 절에 영향을 줌
• 실무에서 추천하는 방법
  • 가급적 묵시적 조인 대신에 명시적 조인을 사용하는 것이 좋다.
  • SQL튜닝 시, 묵시적 조인보다 명시적 조인을 사용해야 튜닝하기 간편함
  • 묵시적 조인은 조인이 일어나는 상황을 한 눈에 파악하기 어렵기 때문

 

 

2. 페치 조인(fetch join)

• SQL의 조인 종류가 아닌 JPQL에서 성능 최적화를 위해 제공하는 기능
• 연관된 엔티티나 컬렉션을 SQL 한 번에 함께 조회하는 기능
• JOIN FETCH 명령어 사용
• [LEFT [OUTER] | INNER] JOIN FETCH 조인 경로

 

1) 엔티티 페치 조인

• 회원을 조회하면서 연관된 팀도 함께 조회(SQL 한 번에)
• SQL을 보면 회원 뿐만 아니라 팀(T.*)도 함께 SELECT

[JPQL] 
SELECT m FROM Member m JOIN FETCH m.team

[SQL]
SELECT M.*, T.* FROM MEMBER M
INNER JOIN TEAM T ON M.TEAM_ID = T.ID

 

2) 컬렉션 페치 조인

• 일대다 관계, 컬렉션 페치 조인

[JPQL]
select t
from Team t join fetch t.members
where t.name = ‘TEAM_A' 

[SQL]
SELECT T.*, M.*
FROM TEAM T
INNER JOIN MEMBER M ON T.ID=M.TEAM_ID
WHERE T.NAME = 'TEAM_A'

 

 

3) 페치 조인과 DISTINCT

• SQL의 DISTINCT는 중복된 결과를 제거함
• JPQL에서의 DISTINCT는 2가지 기능이 있음.
  • SQL의 DISTINCT 기능
  • 애플리케이션에서 엔티티 중복 제거 기능

 

 

4) 페치 조인 vs 일반 조인

• 일반 조인 실행 시 연관된 엔티티를 함께 조회하지 않음
• JPQL은 결과를 반환할 때 연관관계 고려하지 않음
• 단지 SELECT 절에 지정한 엔티티만 조회함
• 페치 조인을 사용할 때만 연관된 엔티티도 함께 조회(즉시 로딩)
• 페치 조인은 객체 그래프를 SQL 한 번에 조회하는 개념
• 아래의 쿼리에서는 팀 엔티티만 조회하고 조인된 멤버는 조회하지 않음(일반조인이기 때문)

[JPQL]
select t
from Team t join t.members m
where t.name = ‘TEAM_A' 

[SQL]
SELECT T.*
FROM TEAM T
INNER JOIN MEMBER M ON T.ID=M.TEAM_ID 
WHERE T.NAME = 'TEAM_A'

 

 

5) 페치 조인의 특징과 한계

• 페치 조인 대상에는 별칭을 줄 수 없다.(하이버네이트는 가능하지만 가급적 사용 X)
• 둘 이상의 컬렉션은 페치 조인 할 수 없음
• 컬렉션을 페치 조인하면 페이징을 사용할 수 없음(생각대로 작동X)
  • 일대일, 다대일 같은 단일 값 연관 필드들은 페치 조인해도 페이징 사용 가능
  • 하이버네이트는 경고 로그를 남기고 메모리에서 페이징 (매우 위험)
• 연관된 엔티티들을 SQL 한 번으로 조회 (성능 최적화)
• 엔티티에 직접 적용하는 글로벌 로딩 전략보다 우선함 ex) @OneToMany(fetch = FetchType.LAZY) 
• 실무에서 글로벌 로딩 전략은 모두 지연 로딩
• 최적화가 필요한 곳은 페치 조인 적용

참고) batch_fetch_size를 지정하면 관련 데이터도 한 번에 조회 가능

 

6) 페치 조인 정리

• 모든 것을 페치 조인으로 해결할 수는 없음
• 페치 조인은 객체 그래프를 유지할 때 사용하면 효과적
• 여러 테이블을 조인해서 엔티티가 가진 모양이 아닌 전혀 다른 결과를 내야 하면, 페치 조인보다는 일반 조인을 사용하고 필요한 데이터들만 조회해서 DTO로 반환하는 것이 효과적임

 

 

3. 다형성 쿼리

1) TYPE

• 조회 대상을 특정 자식으로 한정

ex) Item 중에 Book, Movie를 조회

[JPQL]
select i from Item i
where type(i) IN (Book, Movie) 

[SQL]
select i from i
where i.DTYPE in (‘B’, ‘M’)

 

 

2) Treat (JPA 2.1)

• 자바의 타입 캐스팅과 유사
• 상속 구조에서 부모 타입을 특정 자식 타입으로 다룰 때 사용
• FROM, WHERE, SELECT(하이버네이트 지원) 사용

ex) 부모인 Item과 자식 Book가 있을 때

[JPQL]
select i from Item i
where treat(i as Book).auther = ‘kim’ 

[SQL]
select i.* from Item i
where i.DTYPE = ‘B’ and i.auther = ‘kim’

 

 

4. 엔티티 직접 사용

• JPQL에서 엔티티를 직접 사용하면 SQL에서 해당 엔티티의 기본 키 값을 사용함

[JPQL]
select count(m.id) from Member m 	//엔티티의 아이디를 사용
select count(m) from Member m 		//엔티티를 직접 사용 

[SQL](위의 두 JPQL은 같은 SQL 실행)
select count(m.id) as cnt from Member m

// 엔티티를 파라미터로 전달
String jpql = “select m from Member m where m = :member”; 
List resultList = em.createQuery(jpql).setParameter("member", member).getResultList(); 

// 식별자를 직접 전달
String jpql = “select m from Member m where m.id = :memberId”; 
List resultList = em.createQuery(jpql).setParameter("memberId", memberId).getResultList();

 

 

5. Named 쿼리 (정적 쿼리)

• 미리 정의해서 이름을 부여해두고 사용하는 JPQL
• 정적 쿼리
• 어노테이션(@NamedQuery), XML(META-INF/persistence.xml)에 정의해두고 사용
• 애플리케이션 로딩 시점에 쿼리를 검증
• 애플리케이션 로딩 시점에 초기화 후 재사용
• Named 쿼리 환경에 따른 설정
  • XML이 항상 우선권을 가짐
  • 애플리케이션 운영 환경에 따라 다른 XML을 배포할 수 있음

 

 

6. 벌크 연산

• 재고가 10개 미만인 모든 상품의 가격을 10% 상승하려면?
• JPQ 변경 감지 기능으로 실행하려면 너무 많은 SQL 실행됨
  1. 재고가 10개 미만인 상품을 리스트로 조회
  2. 상품 엔티티의 가격을 10%씩 증가
  3. 트랜잭션 커밋 시점에 변경감지가 동작, 변경된 엔티티의 수만큼 UPDATE SQL이 실행

 

1) executeUpdate()

• 쿼리 한 번으로 여러 테이블 로우 변경(엔티티)
• executeUpdate()의 결과는 영향받은 엔티티의 수를 반환
• executeUpdate() 호출 시, em.flush() 자동 호출
• UPDATE, DELETE 지원
• INSERT(insert into .. select, 하이버네이트 지원)

String qlString = "update Product p " +
                  "set p.price = p.price * 1.1 " + 
                  "where p.stockAmount < :stockAmount"; 
 
int resultCount = em.createQuery(qlString) 
                    .setParameter("stockAmount", 10) 
                    .executeUpdate();

 

2) 벌크 연산 주의

• 벌크 연산은 영속성 컨텍스트를 무시하고 데이터베이스에 직접 쿼리
• 해결책 
  • 벌크 연산을 먼저 실행 
  • 벌크 연산 수행 후 영속성 컨텍스트 초기화