4-6. 주문 조회 V5: JPA에서 DTO 직접 조회 - 컬렉션 조회 최적화

V4에서 N+1문제를 고쳐보자.

 

Order쿼리가 10개라면 10개가 더 나감.

 

 

(혹시나

여기서 =으로 못한다 orderIds는 컬렌션 List<OrderQueryDto> 이기 때문이다.

)

 

Map으로 가져와서 (메모리에서 ) result의 orderItems 값을 세팅.

 

V4는 루프를 돌릴 때마다 쿼리를 날렸는데 V5는 쿼리를 한 번 날리고 Map으로 다 가져온다음에 메모리에서 reulst의 orderItems 값을 세팅해줌.

-> 쿼리가 총 2 번 나감.

->

1번

1번 중 findorders()

2번

 

==

1번의 쿼리

 

2번의 쿼리

2번을 보면 in 쿼리로 한 번에 쓸어온다.

 

1번 쿼리 설명 : order 가져올 때 member, delivery 조인

2번 쿼리 설명 : orderitem, item 조인, order_id관련 in 쿼리

 

 

 

V5의 핵심 : 

메모리인 Map에 올려 두는게 핵심. -> 여러번 쿼리 불필요 -> Map에서 찾아서 넣기.

 

 

 

# 리팩토링 ( Extract Method ) ctrl alt m

 

 

 

 

 

 

# 정리

페치조인보다 이 방법(DTO로 바로 뽑는방법) 이 데이터 SELECT적게하는(필요한것만하는) 장점이있긴하다.(미비함)

 

지금 쿼리 2번인데 다음시간에 1번으로 줄여본다.

 

 

 

 

 

# V4 와 V5의 차이

둘다 JPA에서 DTO 직접 조회라 SELECT 쿼리는 필요한 것만 가져옴. -> loop마다 쿼리날리느냐 마냐 차이.

v4는 loop마다 쿼리 날려서 orderitem 가져오는 반면, v5는 IN쿼리로 처음 loop에 orderitem을 다 가져와서 item까지 한번에 조회

 

1. V4

1. order과 member, delivery 조인

2. 첫 루프에서 orderitem 하나 가져온후 item 조인

3. 두번째 루프에서 orderitem 하나 가져온 후 item 조인

 

 

1. V5

1. order과 member, delivery 조인

2. 첫 루프에서 orderitem 모두 가져온 후 item 조인

 

 

-> 쿼리가 두 개로 줄었다. (IN 쿼리, orderitem한번에 메모리로 가져옴)

 다음시간에 1번으로 줄여본다.