[자바 ORM 표준] 객체지향 쿼리 언어2(JPQL)

June 4, 2022 6 분 소요

객체지향 쿼리 언어1(JPQL)

경로 표현식

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

select m.username -> 상태 필드
 from Member m
join m.team t -> 단일 값 연관 필드
join m.orders o -> 컬렉션 값 연관 필드
where t.name = '팀A'

상태 필드(state field): 단순히 값을 저장하기 위한 필드
- Ex) m.username
연관 필드(association field): 연관관계를 위한 필드
- 단일 값 연관 필드
  - @ManyToOne, @OneToOne, 대상이 엔티티
  - Ex) m.team
- 컬렉션 값 연관 필드
  - @OneToMany, @ManyToMany, 대상이 컬렉션
  - Ex) m.orders

특징

상태 필드(state field): 경로 탐색의 끝, 더 이상 탐색X
단일 값 연관 필드: 묵시적 내부 조인(inner join) 발생, 추가 탐색 가능
컬렉션 값 연관 필드: 묵시적 내부 조인 발생, 더 이상 탐색X
- FROM 절에서 명시적 조인을 통해 별칭을 얻으면 별칭을 통해 탐색 가능
- Ex) select m.username From Team t join t.members m
실무에서는 명시적 Join을 사용!

상태 필드 경로 탐색

JPQL: select m.username, m.age from Member m
SQL: select m.username, m.age from Member m

단일 값 연관 경로 탐색

JPQL: select o.member from Order o
SQL: select m.* from Orders o
inner join Member m ON o.member_id = m.id

명시적 조인, 묵시적 조인

명시적 조인: join 키워드 직접 사용
- select m from Member m join m.team t
묵시적 조인: 경로 표현식에 의해 묵시적으로 SQL 조인 발생(내부 조인만 가능)
- select m.team from Member m

묵시적 조인 시 주의사항

항상 내부 조인
컬렉션은 경로 탐색의 끝, 명시적 조인을 통해 별칭을 얻어야 함
경로 탐색은 주로 SELECT, WHERE 절에서 사용하지만, 묵시적 조인으로 인해 SQL의 FROM(JOIN) 절에 영향을 준다.

[실무 조언]

가급적 묵시적 조인 대신에 명시적 조인 사용

조인은 SQL 튜닝에 중요 포인트

묵시적 조인은 조인이 일어나는 상황을 한 눈에 파악하기 어렵다.

패치 조인(fetch join)

실무에서 정말 중요함!!

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

엔티티 패치 조인

회원을 조회하면서 연관된 팀도 함께 조회(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

패치 조인 사용

패치 조인 사용 전

String query = "select m From Member m";

...

System.out.println("username = " + member.getUsername() + ", " +
                  "teamName = " + member.getTeam().name());

join fetch를 사용하지 않고 조회를 했다.
회원 조회시(SQL) / 회원1, 팀A(SQL) / 회원2, 팀A(1차 캐시) / 회원3, 팀B(SQL)
총 3번의 쿼리가 발생한다.

패치 조인 사용

String jpql = "select m from Member m join fetch m.team";
List<Member> members = em.createQuery(jpql, Member.class) 
                    .getResultList();

for (Member member : members) {
    //패치 조인으로 회원과 팀을 함께 조회해서 지연 로딩X
    System.out.println("username = " + member.getUsername() + ", " +
                  "teamName = " + member.getTeam().name());
}

패치 조인을 사용하게 되면 사용전 예제와는 다르게 쿼리 한번으로 모두 조회가 끝난다.

출력 결과

username = 회원1, teamname = 팀A 
username = 회원2, teamname = 팀A 
username = 회원3, teamname = 팀B

컬렉션 패치 조인

일대다 관계, 컬렉션 패치 조인
[JPQL]
- select t from Team t join fetch t.members
  where t.name = ‘팀A’
[SQL]
- SELECT T.*, M.* FROM TEAM T
  INNER JOIN MEMBER M ON T.ID=M.TEAM_ID
  WHERE T.NAME = ‘팀A’

컬렉션 패치 조인 사용

String jpql = "select t from Team t join fetch t.members where t.name = '팀A'" 
List<Team> teams = em.createQuery(jpql, Team.class).getResultList(); 

for(Team team : teams) {
    System.out.println("teamname = " + team.getName() + ", team = " + team); 
    for (Member member : team.getMembers()) { 
        //페치 조인으로 팀과 회원을 함께 조회해서 지연 로딩 발생 안함
        System.out.println("-> username = " + member.getUsername()+ ", member = " + member); 
    } 
}

출력 결과

teamname = 팀A, team = Team@0x100 
-> username = 회원1, member = Member@0x200 
-> username = 회원2, member = Member@0x300 
teamname = 팀A, team = Team@0x100 
-> username = 회원1, member = Member@0x200 
-> username = 회원2, member = Member@0x300 

Team과 Member를 join fetch하여 ‘팀A’를 조회한 결과 중복되어 조회된다.

패치 조인과 DISTINCT

SQL의 DISTINCT는 중복된 결과를 제거하는 명령
JPQL의 DISTINCT는 2가지 기능 제공
- 1.SQL에 DISTINCT를 추가
- 2.애플리케이션에서 엔티티 중복 제거
select distinct t from Team t join t.members
where t.name=’팀A’
SQL에 DISTINCT를 추가하지만 데이터가 다르므로 SQL 결과에서 중복제거 실패

Member.id와 name이 다르기 때문에 DISTINCT가 되지 않는다.
완전히 같아야 DISTINCT 된다.
DISTINCT가 추가로 애플리케이션에 올라올 때 중복 제거를 시도한다.

같은 식별자를 가진 Team 엔티티 제거

[DISTINCT 추가시 결과]
teamname = 팀A, team = Team@0x100 
-> username = 회원1, member = Member@0x200 
-> username = 회원2, member = Member@0x300

패치 조인 VS 일반 조인

일반 조인 실행시 연관된 엔티티를 함께 조회하지는 않는다.
[JPQL]
- select t from Team t join t.members m
  where t.name = ‘팀A’
- select 절에는 team만 가져오고 join만 추가된다.
- 따라서, 로딩시 member의 값은 없고, 추후에 값 사용시 member 조회 쿼리가 나간다.
패치 조인은 실행시 연관된 엔티티도 함께 조회한다.
- [JPQL]
  - select t from Team t join fetch t.members
    where t.name = ‘팀A’
  - select 절에 team과 member를 다 가져오기 때문에 member에 대한 추가 쿼리가 없다.

차이점 정리

JPQL은 결과를 반환할 때 연관관계 고려X
단지 SELECT 절에 지정한 엔티티만 조회한다.
따라서 일반 조인은 팀 엔티티만 조회하고, 회원 엔티티는 조회하지 않는다.
패치 조인을 사용할 때만 연관된 엔티티도 함께 조회한다.(즉시 로딩)
패치 조인은 객체 그래프를 SQL 한번에 조회하는 개념

패치 조인의 한계와 특징

패치 조인 대상에는 별칭 사용X
- 하이버네이트는 가능하지만, 가급적 사용X
둘 이상의 컬렉션은 패치 조인 할 수 없다.
- 하나의 컬렉션만 패치 조인해도 값이 뻥튀기 되기 때문에 2개를 조회하면 더..
컬렉션을 패치 조인하면 페이징 API(setFirstResult, setMaxResult) 사용 X
- Ex) ‘팀A’조회시 2개의 값이 조회되었는데, setMaxResult(1)로 하게 되면 값이 짤리게된다.
- 하이버네이트는 경고 로그를 남기고 메모리에서 페이징(매우 위험)
- 일대일, 다대일 같은 단일 값 연관 필드들은 패치 조인해도 페이징 가능
연관된 엔티티들은 SQL 한 번으로 조회 - 성능 최적화
엔티티에 직접 적용하는 글로벌 로딩 전략보다 우선함
- @OneToMany(fetch = FetchType.LAZY) // 글로벌 로딩 전략
실무에서 글로벌 로딩 전략은 모두 지연 로딩
최적화가 필요한 곳은 패치 조인 적용

패치 조인 - 정리

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

다형성 쿼리

TYPE

조회 대상을 특정 자식으로 한정
Ex) Item 중에 Book, Movie 조회
[JPQL]
- select i from Item i
  where type(i) IN (Book, Movie)
[SQL]
- select i from Item i
  where i.DTYPE in(‘B’, ‘M’)

TREAT(JPA 2.1)

자바의 타입 캐스팅과 유사
상속 구조에서 부모 타입을 특정 자식 타입으로 다룰 때 사용
FROM, WHERE, SELECT(하이버네이트 지원) 사용
Ex) 부모인 Item과 자식 Book
[JPQL]
- select i from Item i
  where treat(i as Book).author = ‘kim’
- 다운 캐스팅과 유사
[SQL]
- select i.* from Item i
  where i.DTYPE = ‘B’ and i.author = ‘kim’

엔티티 직접 사용

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

외래 키 값

Team team = em.find(Team.class, 1L);

String qlString = "select m from Member m where m.team = :team"; 
List resultList = em.createQuery(qlString) 
            .setParameter("team", team) 
            .getResultList(); 

실행된 SQL
select m.* from Member m where m.team_id=?

Named 쿼리

미리 정의해서 이름을 부여해두고 사용하는 JPQL
정적 쿼리
어노테이션, XML에 정의
애플리케이션 로딩 시점에 초기화 후 재사용
애플리케이션 로딩 시점에 쿼리를 검증
- 쿼리에 오타나 문제가 있을 시 로딩 시점에 잡아준다.
- 실무에서는 Spring Data JPA에서 제공하는 @Query를 사용한다.

@Entity
@NamedQuery(
        name = "Member.findByUsername",
        query="select m from Member m where m.username = :username")
public class Member {
    ...
}

----------------------------------

List<Member> resultList = 
 em.createNamedQuery("Member.findByUsername", Member.class)
        .setParameter("username", "회원1")
        .getResultList();

벌크 연산

(SQL의 UPDATE, DELETE와 비슷)

Ex) 재고가 10개 미만인 모든 상품의 가격을 10% 상승시키려면?
JPA 변경 감지 기능으로 실행하려면 너무 많은 SQL이 실행
- 1.재고가 10개 미만인 상품을 리스트로 조회
- 2.상품 엔티티의 가격을 10% 증가
- 3.트랜잭션 커밋 시점에 변경감지 동작
변경된 데이터가 100건이라면 100번의 UPDATE SQL 실행

예제

쿼리 한 번으로 여러 테이블 로우 변경(엔티티)
executeUpdate()의 결과는 영향받은 엔티티 수 반환
UPDATE, DELETE 지원
INSERT(insert into .. select, 하이버네이트 지원)
Ex) 모든 회원의 나이를 20으로 설정
- em.createQuery(“update Member m set m.age = 20”)
  .executeUpdate();

벌크 연산 주의

벌크 연산은 영속성 컨텍스트를 무시하고 데이터베이스에 직접 쿼리
- 위 예시에서 벌크 연산을 실행 후 영속성 컨텍스트에 있는 회원들의 나이를 조회하면 null이 반환된다.
사용 시 방법
- 벌크 연산을 먼저 실행
- 벌크 연산 수행 후 영속성 컨텍스트 초기화

<출처 : 인프런 - 자바 ORM 표준 JPA 프로그래밍 - 기본편 (김영한)>

Twitter Facebook LinkedIn

[자바 ORM 표준] 객체지향 쿼리 언어2(JPQL)

경로 표현식

특징

상태 필드 경로 탐색

단일 값 연관 경로 탐색

명시적 조인, 묵시적 조인

묵시적 조인 시 주의사항

패치 조인(fetch join)

엔티티 패치 조인

패치 조인 사용

컬렉션 패치 조인

컬렉션 패치 조인 사용

패치 조인과 DISTINCT

패치 조인 VS 일반 조인

차이점 정리

패치 조인의 한계와 특징

패치 조인 - 정리

다형성 쿼리

TYPE

TREAT(JPA 2.1)

엔티티 직접 사용

외래 키 값

Named 쿼리

벌크 연산

예제

벌크 연산 주의

공유하기

댓글남기기

참고

[독서] 돈의속성

[독서] 부자 아빠 가난한 아빠

[독서] 부자 아빠 가난한 아빠

[취업] SKCT 후기