경로 표현식
- .(점)을 찍어 객체 그래프를 탐색하는 것
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) 발생, 탐색O
- 컬렉션 값 연관 경로: 묵시적 내부 조인 발생, 탐색X
- FROM 절에서 명시적 조인을 통해 별칭을 얻으면 별칭을 통해 탐색 가능
상태 필드
String query = "select m.username From Member m"; //상태 필드
List<Member> result = em.createQuery(query, Member.class).getResultList();
for (Member s : result) {
System.out.println("s = " + s);
}단일 값 연관 경로
String query = "select m.team From Member m"; //단일 값 연관 경로
List<Team> result = em.createQuery(query, Team.class).getResultList();
for (Team s : result) {
System.out.println("s = " + s);
}컬렉션 값 연관 경로
String query = "select m From Team t join t.members m"; //컬렉션 값 연관 경로
List<Member> result = em.createQuery(query, Member.class).getResultList();
for (Member s : result) {
System.out.println("s = " + s);
}경로 탐색을 사용한 묵시적 조인 시 주의사항
- 항상 내부 조인
- 컬렉션은 경로 탐색의 끝, 명시적 조인을 통해 별칭을 얻어야함
- 경로 탐색은 주로 SELECT, WHERE 절에서 사용하지만 묵시적 조인으로 인해 SQL의 FROM (JOIN) 절에 영향을 준다.
실무 조언
- 가급적 묵시적 조인 대신에 명시적 조인 사용
- 조인은 SQL 튜닝에 중요 포인트
- 묵시적 조인은 조인이 일어나는 상황을 한눈에 파악하기 어려움
JPQL - 페치 조인(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
위 상황을 페치 조인을 사용해 조회해본다.
Team teamA=newTeam();
teamA.setName("teamA");
em.persist(teamA);
Team teamB=newTeam();
teamB.setName("teamB");
em.persist(teamB);
Member member1=newMember();
member1.setUsername("member1");
member1.setType(MemberType.ADMIN);
member1.setAge(10);
em.persist(member1);
Member member2=newMember();
member2.setUsername("member2");
member2.setType(MemberType.ADMIN);
member2.setAge(11);
em.persist(member2);
Member member3=newMember();
member3.setUsername("member3");
member3.setType(MemberType.ADMIN);
member3.setAge(12);
em.persist(member3);
member1.changeTeam(teamA);
member2.changeTeam(teamA);
member3.changeTeam(teamB);
em.flush();
em.clear();
String query = "select m From Member m join fetch m.team";
List<Member> result = em.createQuery(query, Member.class).getResultList();
for (Member s: result) {
System.out.println("s = " + s.getUsername()+ ", "+ s.getTeam().getName());
}
tx.commit();
결과가 잘 나오는 것을 확인할 수 있다.
여기서 의문은 만약 페치 조인을 사용하지 않으면 어떻게 나오게 될까이다.
그러므로
String query = "select m From Member m";로 수정해서 돌려보면
결과 진행 경로
- 회원1 , 팀A(SQL) //쿼리 나감
- 회원2 , 팀A(1차캐시)
- 회원3 , 팀B(SQL) //쿼리 나감.
결론
- 페치 조인을 사용하지 않고 회원이 100명이고 팀이 다 다르다면 ? ->N+1번 쿼리가 나가게 된다.
- 고로 성능 최적화를 위해 페치 조인을 사용한다.
페치 조인과 DISTINCT
- SQL의 DISTINCT는 중복된 결과를 제거하는 명령
- JPQL의 DISTINCT 2가지 기능 제공
- SQL에 DISTINCT를 추가
- 애플리케이션에서 엔티티 중복 제거
예)
String query = "select distinct m From Team m join fetch m.members";
- DISTINCT가 추가로 애플리케이션에서 중복 제거시도
- 같은 식별자를 가진 Team 엔티티 제거
하이버네이트6 변경 사항
- DISTINCT가 추가로 애플리케이션에서 중복 제거시도
- -> 하이버네이트6 부터는 DISTINCT 명령어를 사용하지 않아도 애플리케이션에서 중복 제거가 자동으로 적용됩니다.
페치 조인과 일반 조인의 차이
- 일반 조인 실행시 연관된 엔티티를 함께 조회하지 않음
- JPQL은 결과를 반환할 때 연관관계 고려X
- 단지 SELECT 절에 지정한 엔티티만 조회할 뿐
페치 조인의 특징과 한계
- 페치 조인 대상에는 별칭을 줄 수 없다.
- 하이버네이트는 가능, 가급적 사용X
- 둘 이상의 컬렉션은 페치 조인 할 수 없다.
- 컬렉션을 페치 조인하면 페이징 API(setFirstResult, setMaxResults)를 사용할 수 없다.
- 일대일, 다대일 같은 단일 값 연관 필드들은 페치 조인해도 페이징 가능
- 하이버네이트는 경고 로그를 남기고 메모리에서 페이징 (매우 위험!)
- 연관된 엔티티들을 SQL 한 번으로 조회 - 성능 최적화
- 엔티티에 직접 적용하는 글로벌 로딩 전략보다 우선함
- @OneToMany(fetch = FetchType.LAZY) //글로벌 로딩 전략
- 실무에서 글로벌 로딩 전략은 모두 지연 로딩
- 최적화가 필요한 곳은 페치 조인 적용
페치 조인 - 정리
- 모든 것을 페치 조인으로 해결할 수 는 없다.
- 페치 조인은 객체 그래프를 유지할 때 사용하면 효과적이다.
- 여러 테이블을 조인해서 엔티티가 가진 모양이 아닌 전혀 다른 결과를 내야 하면, 페치 조인 보다는 일반 조인을 사용하고 필요한 데이터들만 조회해서 DTO로 반환하는 것이 효과적이다.
JPQL - 엔티티 직접 사용
- JPQL에서 엔티티를 직접 사용하면 SQL에서 해당 엔티티의 기본 키 값을 사용
[JPQL]
select count(m.id) from Member m //엔티티의 아이디를 사용
select count(m) from Member m //엔티티를 직접 사용[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(); 엔티티 직접 사용 - 외래 키 값
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();String qlString = "select m from Member m where m.team.id = :teamId";
List resultList = em.createQuery(qlString)
.setParameter("teamId", teamId)
.getResultList();Named 쿼리 - 정적 쿼리
- 미리 정의해서 이름을 부여해두고 사용하는 JPQL
- 정적 쿼리
- 어노테이션, XML에 정의
- 애플리케이션 로딩 시점에 초기화 후 재사용
- 애플리케이션 로딩 시점에 쿼리를 검증
@Entity
@NamedQuery(
name = "Member.findByUsername",
query="select m from Member m where m.username = :username"
)List<Member> resultList =
em.createNamedQuery("Member.findByUsername", Member.class)
.setParameter("username", "회원1")
.getResultList();벌크 연산
만약 재고가 10개 미만인 모든 상품의 가격을 10% 상승하려면?
JPA 변경 감지 기능으로 실행하려면 너무 많은 SQL 실행
1. 재고가 10개 미만인 상품을 리스트로 조회한다.
2. 상품 엔티티의 가격을 10% 증가한다.
3. 트랜잭션 커밋 시점에 변경감지가 동작한다.
-> 변경된 데이터가 100건이라면 100번의 UPDATE SQL 실행
이를 해결하기 위해서 필요한 것이 벌크 연산이다.
- 쿼리 한 번으로 여러 테이블 로우 변경(엔티티)
- executeUpdate()의 결과는 영향받은 엔티티 수 반환
- 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();벌크 연산 주의
- 벌크 연산은 영속성 컨텍스트를 무시하고 데이터베이스에 직접 쿼리
- 벌크 연산을 먼저 실행
- 벌크 연산 수행 후 영속성 컨텍스트 초기화해야 한다.
열심히 하기 1일차