4-6. 주문 조회 V5: JPA에서 DTO 직접 조회 - 컬렉션 조회 최적화
V4에서 N+1문제를 고쳐보자.
Order쿼리가 10개라면 10개가 더 나감.
(혹시나
)
Map으로 가져와서 (메모리에서 ) result의 orderItems 값을 세팅.
V4는 루프를 돌릴 때마다 쿼리를 날렸는데 V5는 쿼리를 한 번 날리고 Map으로 다 가져온다음에 메모리에서 reulst의 orderItems 값을 세팅해줌.
-> 쿼리가 총 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번으로 줄여본다.