> For the complete documentation index, see [llms.txt](https://heunnajo.gitbook.io/jpa-2-api/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://heunnajo.gitbook.io/jpa-2-api/4.-api/v3.1-dto.md). # 주문 조회 V3.1: 엔티티를 DTO로 변환 - 페이징과 한계 돌파 **결론**\ ToOne 관계는 페치 조인해도 페이징에 영향을 주지 않는다. \ \=>**ToOne 관계는 페치조인으로 쿼리 수를 줄이고 해결**하고, **나머지는 hibernate.default\_batch\_fetch\_size 로 최적화** 하자. **정리**\ **fetch join로 한번에 데이터 조획가능하지만 컬렉션은 fetch join을 사용하면 페이징을 하지 못하기 때문에**\ **컬렉션을 지연로딩으로 하되, N+1 문제를 방지하기 위해 batch size를 설정함으로써 한계를 극복한다!** xToOne은 fetch join을 해도 데이터를 증가시키지 않기 때문에 Order와 연관된 xToOne 관계인 member, delivery는 fetch join을 해도 된다! fetch join을 계속하더라도 데이터, row가 증가하는 게 아니라 하나의 row에 옆으로 member, delivery 이런 식으로 늘어나는 것이기 때문이다. 하지만 일대다 관계인 orderItems(oi)와 이 oi와 연관된 item은 fetch join 하면 안된다‼️\ \=>컬렉션은 지연 로딩으로 조회한다!(fetch join❌) 지연 로딩 성능 최적화를 위해 hibernate.default\_batch\_fetch\_size , @BatchSize 를 적용한다. * hibernate.default\_batch\_fetch\_size: 글로벌 설정 * @BatchSize: (엔티티)개별 최적화 * 이 옵션을 사용하면 컬렉션이나, 프록시 객체를 한꺼번에 설정한 size 만큼 IN 쿼리로 조회한다. 보통 N+1 문제는 하나씩 가져오기 때문에 발생한다. 하지만 batch size를 적용하면 이 크기만큼 미리 가져온다! ```java public List findAllWithItem() { return em.createQuery( "select distinct o from Order o" + " join fetch o.member m" + " join fetch o.delivery d" + " join fetch o.orderItems oi" + " join fetch oi.item i", Order.class)//order와 orderItems를 조인! ex) 주문 한건에 주문상품 4개면 조인하면 결과는 4개가 된다. .getResultList(); } ``` N+1, SQL 쿼리 분석 1. findAllWithMemberDelivery 전체 쿼리(creatQuery) Member와 Dlivery fetch join 주문1 : 3개 1. OrderItems 컬렉션 조회 2. orderItem1 > Item 3. orderItem2 > Item 주문2 : 3개 1. OrderItems 컬렉션 조회 2. orderItem1 > Item 3. orderItem2 > Item ```java @GetMapping("/api/v3.1/orders") public List ordersV3_page() { List orders = orderRepository.findAllWithMemberDelivery(); List result = orders.stream() .map(o -> new OrderDto(o)) .collect(Collectors.toList()); return result; } ``` **batch size = 100개 설정**한 후 SQL 분석 : 총 3개의 SQL 1. findAllWithMemberDelivery 전체 쿼리(createQuery) 2. **OrderItems 컬렉션 조회 : userA, userB의 orderItems를 한번에 들고옴.** 3. **Item 조회 : userA 주문 상품>item 2개, userB 주문 상품>item 2개 => 4개를 한번에 들고옴.** **List\ orders 컬렉션과 관련된 것들을 in 쿼리로 가져온다.//batch size**\ **1xNxM => 1x1x1**\ **=>웬만한 경우 원하는 성능이 나온다! 하지마나 실시간으롤 더 빠른 조회 서비스를 제공하고자 한다면 Redis 캐시 사용하거나 DB의 한줄씩 normalization(정규화)** ```java @GetMapping("/api/v3.1/orders") public List ordersV3_page( @RequestParam(value="offset",defaultValue = "0") int offset, @RequestParam(value="limit",defaultValue = "100") int limit) { List orders = orderRepository.findAllWithMemberDelivery(offset,limit); List result = orders.stream() .map(o -> new OrderDto(o)) .collect(Collectors.toList()); return result; } ``` 이전 버전에 비해 쿼리는 1번 => 3번으로 되려 증가했지만,\ 이렇게 **batch size를 설정함으로써 페이징과 성능 최적화를 동시에** 할 수 있다! 이전 버전 : SQL 한번으로 원하는 데이터들 한번에 가져올 수 있지만 중복 데이터가 많음!\ 일대다 관계에서 join하면 '다'를 기준으로 join하기 때문에 데이터가 늘어난다!\ \=>DB에서 에플리케이션으로 이 많은 양의 데이터들이 전송된다!!!용량+++++ 장단점이 있다.\ 단건 조회인 경우 데이터 양이 별로 없으면 fetch join이 성능에 이로울 수 있다.\ 하지만 데이터를 한번에 1000개 이상씩 조회할 때 fetch join으로 한번에 하는 것보다 쿼리가 몇 번 더 나가더라도 이 방법이 더 좋을 수도 있다. xToOne 관계 : join fetch 자체를 생략해도 된다?!\ \=> order, member, delivery 각각 따로 조회하기 때문에 네트워크를 더 많이 탄다!\ \=>따라서 **xToOne 관계는 join fetch으로 미리 잡는 게 좋다**!(Member, Dlivery 에 나가는 쿼리 줄일 수 있다!)\ \=>default\_batch fetch size에 의해 개선된다! 개별로 설정하려면 @BatchSize 를 적용하면 된다. (컬렉션은 컬렉션 필드에, 엔티티는 엔티티 클래스에 적용)\ ⭐️**Order 클래스**에서 **List\ 컬렉션 필드**에 **@BatchSize(size=100)**이에요!\ **xToOne 관계**인경우 **가장 상위 클래스에 @BatchSize 적용**\ (현업에서는 주로 전체 설정으로 많이 함.)