[JPA] 객체지향 쿼리 언어 - 중급 문법

2025. 4. 20. 22:19·JPA

경로 표현식


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

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) 

경로 표현식 예제

select o.member.team from Order o -> 성공
select t.members from Team -> 성공
select t.members.username from Team t -> 실패
select m.username from Team t join t.members m -> 성공

 

경로 표현식 특징

  • 상태 필드(state field): 경로 탐색의 끝, 더이상 탐색X
  • 단일 값 연관 경로: 묵시적 내부 조인(inner join) 발생, 탐색O
  • 컬렉션 값 연관 경로: 묵시적 내부 조인 발생, 탐색X
    • FROM 절에서 명시적 조인을 통해 별칭을 얻으면 별칭을 통해 탐색 가능

 

의도하지 않은 내부 조인과 성능 저하를 방지하기 위해서

* 묵시적 조인 쓰지말 것 ➡︎ 명시적 조인

 

단일 값 연관 경로 탐색

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 t from Member m join m.team t

 

경로 탐색을 사용한 묵시적 조인 시 주의사항

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

결론

  • 가급적 묵시적 조인 대신에 명시적 조인 사용
  • 조인은 SQL 튜닝에 중요 포인트
  • 묵시적 조인은 조인이 일어나는 상황을 한눈에 파악하기 어려움

 

페치 조인(fetch join) :  즉시로딩!!


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

my.

select m.team from Member m Team 조회 대상.  team 즉시 로딩 (묵시적 조인, LAZY무시)
select m from Member m join m.team Member 조회대상. m.team에 접근할 때 추가 쿼리 발생 (지연 로딩)
select m from Member m join fetch m.team Member + Team 조회대상. Member와 Team을 한 번에 모두 로딩, 즉시 로딩 강제, LAZY 무시됨, N+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

 

사용코드

Team teamA = new Team();
teamA.setName("teamA");
em.persist(teamA);

Team teamB = new Team();
teamB.setName("teamB");
em.persist(teamB);

Member member = new Member();
member.setUsername("회원1");
member.setTeam(teamA);
em.persist(member);

Member member2 = new Member();
member2.setUsername("회원2");
member2.setTeam(teamA);
em.persist(member2);

Member member3 = new Member();
member3.setUsername("회원3");
member3.setTeam(teamB);
em.persist(member3);

em.flush();
em.clear();
String query = "select m From Member m";

List<Member> result = em.createQuery(query, Member.class).getResultList();

for (Member mem : result) {

    // Member 조회(SQL, 지연로딩)
    /// 회원1. 팀A(SQL)
    //  회원2. 팀A(1차캐시)
    //  회원3. 팀B(SQL)  쿼리 3번 나감
    //  N 명일 때 : N + 1(처음조회) 쿼리 나감...
    System.out.println("Member = " + mem.getUsername() + ", " + mem.getTeam().getName());
}

이럴때 필요한게 패치조인!

String query = "select m From Member m join fetch m.team";

List<Member> result = em.createQuery(query, Member.class).getResultList();

for (Member mem : result) {

    // 조인한 쿼리 한번만 나감, 지연로딩x
    System.out.println("Member = " + mem.getUsername() + ", " + mem.getTeam().getName());
}

 

컬렉션 페치 조인


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

[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.

(데이터 뻥튀기됨)

 

사용코드

String query = "select t From Team t join fetch t.members m where t.name = 'teamA'";

List<Team> result = em.createQuery(query, Team.class).getResultList();

//페치 조인으로 회원과 팀을 함께 조회해서 지연 로딩X
for (Team team : result) {
    System.out.println("teamname = " + team.getName() + ", team = " + team);
    for (Member mem : team.getMembers()){
        System.out.println("membername = " + mem.getUsername() + ", member = " + mem);
    }
}

 

teamname = 팀A, team = Team@0x100

-> username = 회원1, member = Member@0x200

-> username = 회원2, member = Member@0x300

(Hibernate 6에서는 중복 제거는 자동. DISTINCT 자동 추가로 애플리케이션에서 중복 제거 자동 적용됨)

 

***참고

 

원래 데이터뻥튀기로 db기준으로해서

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

이렇게 두줄나옴

 

"select distinct t from Team t join fetch t.members where t.name = '팀A'"

DISTINCT를 추가하지만 데이터가 다르므로 SQL 결과에서 중복제거 실패

jpa에서 DISTINCT가 추가로 애플리케이션에서 중복 제거시도 → 같은 식별자를 가진 Team 엔티티 제거

[DISTINCT 추가시 결과]

teamname = 팀A, team = Team@0x100

-> username = 회원1, member = Member@0x200

-> username = 회원2, member = Member@0x300

***

 

페치 조인과 일반 조인의 차이


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

 [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'

 

페치 조인의 특징과 한계


1. 페치조인 대상에 별칭 못줌

  • From Team t join fetch t.members as m❌
  • 하이버네이트는 가능, 가급적 사용X
  • 멤버 5명 중 3명 뽑았는데 그걸 따로 조작하는건 위험
  • select t From Team t join fetch t.members m join fetch m.team 이런식으로 조인 몇개 거치는건 ㅇㅋ

2. 둘 이상의 컬렉션은 페치 조인 할 수 없다 - 1개의 컬렉션 허용

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;

    private String username;

    @ManyToOne(fetch = LAZY)
    private Team team;

    @OneToMany(mappedBy = "member")
    private List<Order> orders;

    @OneToMany(mappedBy = "member")
    private List<Comment> comments;
}
SELECT m FROM Member m
JOIN FETCH m.orders
JOIN FETCH m.comments

곱집합때문에 데이터가 중복되고, 결과가 예측 불가능해지기 때문에 불가❌

 

 

3. 컬렉션을 페치 조인하면 페이징 API(setFirstResult,setMaxResults)를 사용할 수 없다.

일대일, 다대일 같은 단일 값 연관 필드들은 페치 조인해도 페이징 가능

그런데, 일대다는 데이터 뻥튀기때문에 페이징하기 곤란함

 

시도할 경우 : 하이버네이트는 경고 로그를 남기고 메모리에서 페이징(매우 위험)-
WARN: HHH90003004: firstResult/maxResults specified with collection fetch; applying in memory

 

참고.
Hibernate 6에서는 중복 제거는 자동되지만, DB단에서 페이징이 아닌 중간 결과 전체를 가져와서
메모리에서 중복 제거 후 페이징하는 식이기 때문 → 성능 이슈 발생 가능성 있어 주의해서 쓰거나 피하는게 안전

 

 

그래서 컬렉션 페이징은 어떻게 해야 하나?

패치조인대신

 

1. ToOne 관계에서 Fetch Join

일대다인걸 다대일에서 페치조인 페이징

//select t From Team t join fetch t.members → 
SELECT m FROM Member m JOIN FETCH m.team

 

2. 그냥 조인 페이징 + Batch Size

List<Team> teams = em.createQuery("SELECT t FROM Team t", Team.class)
        .setFirstResult(0)
        .setMaxResults(10)
		.getResultList();
        
for (Team team : teams) {
    System.out.println(team.getMembers().size()); // members는 LAZY
}

근데 teams가 100개있다면, members는 100번 DB 쿼리를 날릴 수 있음 → N+1 문제 생김

 

그래서 쿼리 최소화 위해

✅ Batch Size 설정

@BatchSize(size = 100) //연관된 엔티티 프록시 객체를 한꺼번에 모아서 한 쿼리(IN 절)로 묶어 처리하는 크기
@OneToMany(mappedBy = "team")
private List<Member> members = new ArrayList<>();

또는

hibernate.default_batch_fetch_size=10
<property name="hibernate.default_batch_fetch_size" value="100" />

(깔고가는거 추천)

 

효과

컬렉션 조회할때 설정한 10개 묶는 설정을 했다면

110개팀 → 최대 11번의 쿼리로 처리

쿼리 횟수 감소 → 성능 개선

SELECT * FROM Member WHERE team_id IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)

 

 

3. DTO로 쿼리 직접짜기

 

 

특징

  • 연관된 엔티티들을 SQL 한 번으로 조회 - 성능 최적화
  • 엔티티에 직접 적용하는 글로벌 로딩 전략보다 우선함
    • @OneToMany(fetch = FetchType.LAZY) //글로벌 로딩 전략
  • 실무에서 글로벌 로딩 전략은 모두 지연 로딩
  • 최적화가 필요한 곳은 페치 조인 적용

 

페치 조인 - 정리

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

 

다형성 쿼리


 

TYPE

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

 

예) 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’)

 

TREAT

자바의 타입 캐스팅과 유사

상속 구조에서 부모 타입을 특정 자식 타입으로 다룰 때 사용

FROM, WHERE, SELECT(하이버네이트 지원) 사용

 

예) 부모인 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에서 해당 엔티티의 기본 키 값 사용

my. 조건으로 사용할 때(WHERE 절, JOIN 절, IN 절 등에서 엔티티 자체를 비교하거나 전달하는 경우)

 

기본 키 값

엔티티를 파라미터로 전달

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();

실행된 SQL (같은 결과)

select m.* from Member m where m.id=?

 

외래 키 값

엔티티를 파라미터로 전달

Team team = em.find(Team.class, 1L);
String query = "select m from Member m where m.team = :team";
List resultList = em.createQuery(query)
                                .setParameter("team", team)
                                .getResultList();

식별자를 직접 전달

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

실행된 SQL (같은 결과)

select m.* from Member m where m.team_id=?

 

 

Named 쿼리


@Entity
@NamedQuery( //JPQL 쿼리 미리 정의
	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();
  • 미리 정의해서 이름을 부여해두고 사용하는 JPQL
  • 정적 쿼리
  • 어노테이션, XML에 정의
  • 애플리케이션 로딩 시점에 초기화 후 재사용
  • 애플리케이션 로딩 시점에 쿼리를 검증해줌!

앱 로딩 시점에 쿼리 미리 파싱해 캐시함

 

Spring Data JPA에서 @Query씀

Named 쿼리 - XML에 정의

 

벌크 연산


update, delete 같은 JPQL로 다수의 데이터를 한 번에 처리하는 쿼리

 

만약,재고가 10개 미만인 모든 상품의 가격을 10% 상승하려면?

 

JPA 변경 감지 기능으로 실행하려면 너무 많은 SQL 실행

    1. 재고가 10개 미만인 상품을 리스트로 조회한다.

    2. 상품 엔티티의 가격을 10% 증가한다.

    3. 트랜잭션 커밋 시점에 변경감지가 동작한다.

변경된 데이터가 100건이라면 100번의 UPDATE SQL 실행벌크 연산

 

→ 벌크 연산

: 쿼리 한 번으로 여러 테이블(엔티티) 로우 변경

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(); //**
  • executeUpdate()의 결과는 영향받은 엔티티 수 반환
  • UPDATE, DELETE 지원
  • INSERT(insert into .. select, 하이버네이트 지원)

 

벌크 연산 주의

벌크 연산은 영속성 컨텍스트를 무시하고 데이터베이스에 직접쿼리날림

문제는, 영속성 컨텍스트에 있는 엔티티들은 이 변화 사실을 모름

그래서 벌크 연산 직후에 조회하면, DB 값과 다른 값이 나올 수 있음.

 

Member m1 = em.find(Member.class, 1L);
m1.setAge(10);

//	JPQL 수행 전 flush() 자동 실행
em.createQuery("UPDATE Member m SET m.age = 20").executeUpdate();

System.out.println(m1.getAge()); // 10 출력됨 (DB는 20으로 바뀌었는데도!)

 

 

✓ 해결 방법 2가지

방법1. 벌크 연산을 먼저 실행하고 엔티티를 조회

em.createQuery("UPDATE Member m SET m.age = 20").executeUpdate();

// 그 다음에 조회
Member m1 = em.find(Member.class, 1L); // 20이 제대로 반영됨

방법2. 벌크 연산 이후, 영속성 컨텍스트 초기화

Member m1 = em.find(Member.class, 1L);

em.createQuery("UPDATE Member m SET m.age = 20").executeUpdate();

// 영속성 컨텍스트 초기화
em.clear();

Member m1Refreshed = em.find(Member.class, 1L);
System.out.println(m1Refreshed.getAge()); // 20 출력

'JPA' 카테고리의 다른 글

[JPA] 객체지향 쿼리 언어 - 기본문법  (0) 2025.04.17
[JPA] 값 타입  (0) 2025.04.16
[JPA] 영속성 전이와 고아 객체  (0) 2025.04.15
[JPA] 프록시와 지연 로딩 전략  (0) 2025.04.09
[JPA] 고급 매핑(상속)  (0) 2025.04.06
'JPA' 카테고리의 다른 글
  • [JPA] 객체지향 쿼리 언어 - 기본문법
  • [JPA] 값 타입
  • [JPA] 영속성 전이와 고아 객체
  • [JPA] 프록시와 지연 로딩 전략
Naah
Naah
  • Naah
    blueprint
    Naah
  • 전체
    오늘
    어제
    • 분류 전체보기 (106)
      • Java (28)
      • Kotlin (0)
      • TypeScript (7)
      • React (22)
      • Next.js (1)
      • Spring (22)
      • JPA (12)
      • Spring Data JPA (6)
      • Querydsl (1)
      • Error (7)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
    • 글쓰기
    • manage
  • 링크

  • 공지사항

  • 인기 글

  • 태그

  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.3
Naah
[JPA] 객체지향 쿼리 언어 - 중급 문법
상단으로

티스토리툴바