[JPA] 쿼리 언어 문법 (기본, 중급)
기본: JPA에서 지원하는 쿼리 방법
- JPQL
: 객체 지향 쿼리
: 동적쿼리를 짜는데 불편. -> 대책: Criteria (실무에서 안 쓴다.)
- QueryDSL
* 특수한 경우만 JDBC API, MyBatis, SpringJdbcTemplate 함께 사용
Note
OneToMany 관계 설정시, 메모리 낭비가 있더라도 바로 초기화하자.
@OneToMany(mappedBy = "team")
private List<Member> members = new ArrayList<>();
@Embedded, @Embedable
1) @Embedded: Entity내 객체에 붙이기 (예. Person 내 Address에)
2) @Embedable: 클래스에 붙이기 (예. Address class 위)
기본: JPQL 문법
기본
- 엔티티와 속성은 대소문자 구분
cf. JPQL 키워드는 대소문자 구분 x
- 별칭 m 필수 (as 생략 가능)
select m from Member as m where m.age > 18- Group by, having 등 안시 기본 문법 모두 지원
TypeQuery, Query
반환 타입 명확할 때 -> TypeQuery
명확하지 않을 때 -> Query (예. select m.name, m.age ....)
getResultList vs getSingleResult
: 결과 하나 이상 vs 결과 정확히 하나
: 주의
-> getResultList는 결과 없으면 빈 리스트 반환
-> getSingleResult: NoResultException, NonUniqueResultException
-> Spring Data JPA에서는 추상화를 통해, 결과 없으면 null 혹은 optional (Exception 안 터짐)
파라메터 바인딩
이름 기준 vs 위치기준
-> 위치 기준 쓰지 말자 (파라메터 하나 새로 추가하면 순서 다 뒤틀림)
프로젝션
select 절에 조회 대상 지정
- 엔티티 (select m from...)
- 임베디드 타입 (select m.address from....)
- 스칼라 타입 (select m.age, m.name from...)
Note: join
안티패턴: 묵시적 조인
List<Team> result = em.createQuery("select m.team from Member m", Team.class)
.getResultList();good: 명시적 조인
ist<Team> result = em.createQuery("select t from Member m join m.team t", Team.class)
.getResultList();
여러값 조회
- Query / Objects[] / new 명령어
- new 명령어 사용 예시 (가장 깔끔)
ist<MemberDto> result = em.createQuery("select new jpql.MemberDto(m.username, m.age) from Member m", MemberDto.class)
.getResultList();
Note
toString 만들 때 양방향 연관관계의 객체는 toString 대상에서 제외할것. (StackOverflow 남)
페이징
String jpql = "select m from member m order by m.name desc";
List<Member> resultList = em.createQuery(jpql, Member.class)
.setFirstResult(1)
.setMaxResult(10)
.getResultList();중첩 depth의 지저분한 쿼리를 (예. mysql) 깔끔하게 만든다.
조인
조인시 주의 사항
- OneToMany 연관관계 맺을 때 fetchJoin 속성을 Lazy로 두자.
종류
- inner join (내부 조인)
- outer join (외부 조인)
- 세타 조인.
조인대상 필터링
SELECT m, t FROM Member m LEFT JOIN m.team t on t.name = 'A'
연관관계 없는 엔티티 외부조인 가능
- JPA 5.x 부터 지원. 기존에는 내부 조인만 지원
- SELECT m, t FROM Member m LEFT JOIN Team t on m.username = t.name
서브 쿼리
정의
쿼리 내 쿼리
select m from Member m where m.age (select avg(m2.aget) from Member m2)
서브쿼리 지원 옵션
- exists / not exists : 존재 여부
- all : 모두 만족
- any / some : 조건 하나라도 만족
- in / not in : 서브쿼리 결과 중 하나라도 만족하면 참
jpa 서브쿼리 한계
- JPA 스펙: where, having 절에서만 사용가능
- hibernate (구현체 일종) 스펙: select 절에서도 가능 (예. select (avg(m2.aget) from Member m2) as avg_age ...)
- from 절의 서브쿼리는 JPQL에서 사용 불가 -> 조인으로 풀어 해결
조건식 (case)
- 기본 CASE 식
: case when m.aget <= 10 then '학생 요금'
- 단순 CASE 식
: case t.name when '팀A' then '인센티브110%'
-> exactly matching
- coalesce: null 아니면 반환
: select coalesce(m.username. '이름 없는 회원') from Member m
- NULLIF: 두 값이 같으면 null 반환, 다르면 첫번째 값 반환
: select NULLIF(m.usernmae, '관리자') from Member m;
JPQL 함수
- 기본 함수
: 안시의 함수 그대로 제공
: 특별 케이스
-> SIZE (예. select size(t.members) from Team t)
-> INDEX -> 사용하지 말자.
- 사용자 정의 함수
: config에 방언 설정
: 예시
select function('group_concat', m.username) From Member m
중급문법
경로 표현식
정의
.을 찍어 객체 그래프 탐색
종류
- 상태 필드 (state field)
:단순히 값을 저장하는 용도
- 연관 필드 (association field)
: 연관관계를 위한 필드
-- 단일 값 연관 필드
: 대상이 엔티티 (m.team)
-- 컬렉션 값 연관 필드
: 대상이 컬렉션 (m.orders)
특징
- 상태 필드(state field): 경로 탐색의 끝. 탐색 x
select m.username from Member m
- 단일값 연관 경로: 묵시적 내부 조인(inner join) 발생. 탐색 o
select m.team.name from Member m -> team에서 다시 name을 탐색
- 컬렉션 값 연관경로: 묵시적 내부조인 발생. 탐색 x.
: (예) select m.members from Team t -> members.xx의 형태로 탐색 불가.
: (대안) select m from Team t join t.members m -> from 절에서 명시적 조인을 사용. 별칭 얻음.
=> 묵시적 조인은 실무에서 쓰지 말자. 쿼리 튜닝이 어려워진다.
패치조인: 개념
-> 실무에서 진짜!!! 중요함
- SQL 조인 종류 아님.
- JPQL에서 성능 최적화 위해 사용
- 연관 엔티티/컬렉션을 SQL 한번에 함께 조회
- join fetch 명령어 사용
엔티티 패치 조인: ManyToOne
select m from Member m join fetch m.team
-> SELECT M.*, T.* FROM MEMBER M INNER JOIN TEAM T ON M.TEAM_ID = T.ID
패치조인 없을 경우 발생하는 N+1 문제 예시
String jpql = "select m from Member m join m.team"
// member 조회 쿼리 1번
List<Member> members = em.createQuery(jpql. Member.class)
.getResultList();
// for 문 돌면서, 영속성 context에 없는 team은 쿼리 날려서 조회
for ( Member member : result) {
System.out.println(member.getTeam().getName());
}-> 대안: select m from Member m join fetch m.team
엔티티 패치 조인: OneToMany / 컬렉션 패치 조인
select t from Team t join fetch t.members where t.name = "팀A"
-> SELECT T.*, M.*
FROM TEAM T I
NNER JOIN MEMBER M ON T.ID = M.TEAM_ID
WHERE T.NAME = '팀A'
주의사항
팀A에 2명, 팀 B에 1명일 경우, 위 쿼리를 실행, 결과값을 for문 돌리면 3줄이 나온다. (데이터 뻥튀기 현상)
-> 해결: DISTINCT
DISTINCT
- SQL: 중복된 결과 제거
- JPQL: (1) SQL에 DISTINCT 추가 (2) 애플리케이션의 엔티티 중복 제거 (=같은 식별자 지닌 엔티티 제거)
예) select distinct t from Team t join fetch t.members
-> (1)에서 distinct 해도 실패(row 결과값은 다르니까). (2)에서 distinct 적용됨.
- SQL: 중복된 결과 제거
- JPQL: (1) SQL에 DISTINCT 추가 (2) 애플리케이션의 엔티티 중복 제거?
예) select distinct t from Team t join fetch t.members
패치조인과 일반 조인의 차이
일반 조인 실행시 연관된 엔티티 함께 조회하지 않는다.
select t
from TEam t join t.members m
where t.name = '팀 A'
->
SELECT T.*
FROM TEAM T
INNER JOIN MEMBER M
ON T.ID = M.TEAM_ID
WHERE T.NAME = '팀 A'
패치조인: 특징 & 한계
1) 패치 조인 대상에는 별칭을 줄 수 없다.
예. select t from Team t join fetch t.members m where m.age > 10
이유: 객체 탐색 그래프의 취지에 어긋난다. team은 members를 전부 담고 있어야한다.
일부분만 가져오는 것은 삭제, 업데이트 등의 행위시 잘못된 결과를 가져올 수 있다.
만일 members에 필터릴 조건을 걸고 싶다면 select m from Members where ...로 따로 쿼리 날리는 것이 맞다.
2) 둘 이상의 컬렉션은 패치 조인 할 수 없다.
이유: 데이터가 일:다:다의 관계가 되어, row 수 급증. -> 정확성 x
3) 컬렉션을 패치 조인하면 페이징 API (setFirstResult, setMaxResults) 사용 불가
: 일대일/다대일은 페이징 사용 가능
이유: 데이터 뻥튀기
: 팀A(회원1,회원2), 팀B(회원3)의 데이터에서, 컬렉션 패치 조인 후 페이징,
0번 row 가져올 때, 팀A는 회원 1만 가진 것으로 잘못 추력됨.
: 하이버네이트에서 실행시 경고 남기고 메모리에서 페이징 (위험)
-> 데이터 100만건이면 paging 걸어도, 백만건 다 긁어옴.
WARN: ... firstResult/maxResults specified with collection fetch; applying in memory!
해결방법
- ManyToOne 쿼리로 대체
- One에 해당하는 Entity에만 Paging 걸고, ManyToOne은 @BatchSize 사용 (강의 15: 56)
정리
실무에서 글로벌 로딩 전략은 모두 지연 로딩 사용하되, 최적화가 필요한 경우 패치 조인 적용
다형성쿼리
타입 지정 가능
엔티티를 직접 사용
JPQL에서 엔티티를 직접 사용시, SQL에서는 해당 엔티티의 기본 키 값을 사용한다.
- select count(m.id) from Member m
- select count(m) from Member m
-> (SQL 실행 결과는 아래 내용으로 같다)
select count(mid) as cnt from Member m
Named 쿼리
- 미리 이름 정의하여 사용하는 JPQL. 정적쿼리
- 사용방법: (1) 애노테이션 (2) XML
- 장점
: 애플리케이션 로딩 시점에 초기화. 캐싱하여 재사용 가능. (JPA-> SQL 컨버팅 비용 절약)
: 애플리케이션 로딩 시점에 쿼리 검증
-> Spring Data JPA에서 @Query("select ~") 로 사용하는 것도 named query의 일종
벌크 연산
- 여러 row 한번에 변경 (updae, delete 지원)
- 하이버네이트는 insert (select ...) into 지원
벌크 연산 주의
- 벌크 연산은 영속성 컨텍스트 무시. 데이터베이스에 직접 쿼리한다.
- 연산 순서 꼬임 방지 방법
방법 1) (영속성 컨텍스트에 아무 작업 없이) 벌크 연산 먼저 수행
방법 2) 벌크 연산 수행 후 영속성 컨텍스트 초기화
방법 2 추가 설명
-> 회원 나이 조회시 10살. 벌크 연산으로 모두 +1살 됨 -> 영속성 컨텍스트에는 여전히 10살로 남아있음. -> 초기화 하지 않으면, DB에는 11살로 나오지만, 애플리케이션에서는 10살로 나오는 오류 발생.
** 영속성 컨텍스트 -> DB 반영 시점
(1) commit (2) 쿼리 날림 (3) flush 호출