[1] 경로 표현식
: .을 찍어 객체 그래프를 탐색하는 것
select m.username
from Member m
join m.team t
join m.orders o
where t.namem.username → 상태 필드
m.team → 단일 값 연관 필드
m.orders → 컬렉션 값 연관 필드
이렇게 3가지 필드가 있음
상태필드(state field)
: 단순히 값을 저장하기 위한 필드
Ex. m.username
연관필드(association field)
: 연관관계를 나타내기 위한 필드
단일 값 연관 필드:
@ManyToOne, OneToOne, 대상이 엔티티(Ex. m.team)
컬렉션 값 연관 필드:
@OneToMany, @ManyToMany, 대상이 컬렉션(Ex. m.orders)
특징
-
상태 필드 (state field): 경로 탐색의 끝. 탐색 X
m.username처럼 또.을 찍어 더 이상 들어갈 수 있는 곳이 없음 -
단일 값 연관 경로: 묵시적 내부 조인(inner join) 발생, 탐색 O
편해보이지만 조심해서 써야한다. 아니다,,
그냥,, 쓰지마라,, -
컬렉션 값 연관 경로: 묵시적 내부 조인 발생, 탐색 X
- FROM 절에서 명시적 조인을 통해 별칭을 얻으면 별칭을 통해 탐색 가능
명시적 조인, 묵시적 조인
명시적 조인: join 키워드 직접 사용
select m from Member m join m.team t
묵시적 조인: 경로 표현식에 의해 묵시적으로 SQL 조인 발생(내부 조인만 가능)
select m.team from Member m
경로 탐색을 사용한 묵시적 조인 시 주의사항
- 항상 내부 조인
- 컬렉션은 경로 탐색의 끝, 명시적 조인을 통해 별칭을 얻어야 함
- 경로 탐색은 주로 select, where 절에서 사용하지만 묵시적 주인으로 인해 SQL의 from (join) 절에 영향을 줌
결국 실무에서는
- 가급적 묵시적 조인 대신 명시적 조인을 사용하자.
- 조인은 SQL 튜닝에 중요 포인트
- 묵시적 조인은 조인이 일어나는 상황을 한눈에 파악하기 어려움
[2] ⭐️⭐️⭐️ JPQL - 페치 조인 1(fetch join) - 기본
페치조인(fetch join)
- SQL 조인 종류가 아님
- JPQL에서 성능 최적화를 위해 제공하는 기능
- 연관된 엔티티나 컬렉션을 SQL 한 번에 함께 조회하는 기능
- join fetch 명령어 사용
- 페치 조인 ::= [LEFT [OUTER] | INNER] JOIN FETCH 조인경로
엔티티 페치 조인
- 회원을 조회하면서 연관된 팀도 함께 조회(SQL 한 번에)
- SQL을 보면 회원 뿐만 아니라 팀(T.*)도 함께 SELECT
페치 조인 사용 코드
컬렉션 페치 조인
- 일대다 관계, 컬렉션 페치 조인(컬렉션인데 페치 조인)
사용 코드
DISTINCT
: 중복이 싫으면 DISTINCT로 제거
- SQL의 DISTINCT는 중복된 결과를 제거하는 명령
- JPQL의 DISTINCT는 2가지 기능을 제공한다.
- SQL에 DISTINCT를 추가
- 애플리케이션 수준에서 엔티티 중복 제거
📌 일대다 조인할 때 데이터가 뻥튀기 될 수 있다. 하지만 반대로 다대일 관계는 뻥튀기 되지 않는다.
select distinct t
from Team t join fetch t.members
where t.name = '팀A'-
SQL에 DISTINCT를 추가하지만 데이터가 다르므로 SQL 결과에서 중복제거 실패
-
DISTINCT가 추가로 애플리케이션에서 중복 제거 시도
-
같은 식별자를 가진 Team 엔티티 제거
페치 조인과 일반 조인의 차이
일반 조인
-
일반 조인 실행시 연관된 엔티티를 함께 조회하지 않음
-
JPQL은 결과를 반환할 때 연관관계를 고려하지 않고 단지 select 절에 지정한 엔티티만 조회할 뿐이다.
-
여기서는 팀 엔티티만 조회하고, 회원 엔티티는 조회하지 않는다.
-
페치 조인을 사용할 때만 연관된 엔티티도 함께 조회(즉시 로딩)
(사실상 즉시 로딩이 발생한다고 보면 된다. 지연 로딩을 지정해줬지만 페치 조인을 사용하면 페치 조인이 우선되므로 즉시로딩 된다.) -
페치 조인은 객체 그래프를 SQL 한 번에 조회하는 개념
페치 조인
- 페치 조인은 연관된 엔티티를 함께 조회함
[3] 페치 조인2 - 한계
-
원칙적으로 페치 조인 대상에는 별칭을 줄 수 없다. (ex. ... as m where m.username)
하이버네이트는 가능. 가급적 사용 하지 않기. -
둘 이상의 컬렉션은 페치 조인할 수 없다.
-
컬렉션을 페치 조인하면 페이징 API(
setFirstResult,setMaxResult)를 사용할 수 없다.
일대일, 다대일 같은 단일 값 연관 필드들은 페치 조인해도 페이징이 가능하다.
하이버네이트는 경고 로그를 남기고 메모리에서 페이징(매우 위험) -
연관된 엔티티들을 SQL 한 번으로 조회 → 성능 최적화
-
엔티티에 직접 적용하는 글로벌 로딩 전략보다 우선시
(글로벌 로딩 전략:@OneToMany(fetch = FetchType.LAZY) -
실무에서 글로벌 로딩 전략은 모두 지연 로딩
-
최적화가 필요한 곳은 페치 조인 적용
즉,
모든 것을 페치 조인으로 해결할 수는 없다. 페치 조인은 객체 그래프를 유지할 때 사용하면 효과적이다.
여러 테이블을 조인해 엔티티가 가진 모양이 아닌 전혀 다른 결과를 내야한다면 페치 조인보다는 일반 조인을 사용하고, 필요한 데이터들만 조회해 DTO로 반환하는 것이 효과적이다.
[4] 다형성 쿼리
별로 중요한 내용 아님
[5] 엔티티 직접 사용
- JPQL에서 엔티티를 직접 사용하면 SQL에서 해당 엔티티의 기본 키 값을 사용한다.
[6] Named 쿼리 - 정적 쿼리
: 미리 정의해서 이름을 부여해두고 사용하는 JPQL
- 정적 쿼리에서만 가능함
- 애노테이션, XML에 정의할 수 있음
- 애플리케이션 로딩 시점에 초기화 후 재사용함
- ⭐️ 애플리케이션 로딩 시점에 쿼리를 검증할 수 있음
@Entity
@NamedQuery(
name = "Member.findByUsername",
query = "select m from Member m where m.username = :username"
)
public class Member {[7] 벌크 연산
만약 재고가 n개 미만인 모든 상품의 가격을 m% 상승시키려면
JPA 변경 감지 기능으로 실행하려면 너무 많은 SQL이 실행된다.
- 재고가 n개 미만인 상품을 리스트로 조회
- 상품 엔티티의 가격을 m% 증가
- 트랜잭션 커밋 시점 변경 감지 동작
이렇게 변경된 데이터가 100건이라면 100번의 UPDATE SQL이 실행된다.
벌크 연산은 쿼리 한 번으로 여러 테이블 로우를 변경할 수 있다.
- executeUpdate()의 결과는 영향받은 엔티티 수 반환
- UPDATE, DELETE 지원
- **INSERT(insert into ... select, 하이버네이트 지원)
주의할 점
- 벌크 연산은 영속성 컨텍스트를 무시하고 데이터베이스에 직접 쿼리를 날린다.
그러므로
- 벌크 연산을 먼저 실행하거나
- 벌크 연산 수행 후 영속성 컨텍스트를 초기화 해줘야 한다.
JPA 너무 어려워,, 조만간 다시 듣는다,,
