# 주문 조회 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<Order> 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<OrderDto> ordersV3_page() {
    List<Order> orders = orderRepository.findAllWithMemberDelivery();

    List<OrderDto> 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\<Order> orders 컬렉션과 관련된 것들을 in 쿼리로 가져온다.//batch size**\
**1xNxM => 1x1x1**\
**=>웬만한 경우 원하는 성능이 나온다! 하지마나 실시간으롤 더 빠른 조회 서비스를 제공하고자 한다면 Redis 캐시 사용하거나 DB의 한줄씩 normalization(정규화)**

```java
@GetMapping("/api/v3.1/orders")
public List<OrderDto> ordersV3_page(
        @RequestParam(value="offset",defaultValue = "0") int offset,
        @RequestParam(value="limit",defaultValue = "100") int limit) {

    List<Order> orders = orderRepository.findAllWithMemberDelivery(offset,limit);

    List<OrderDto> 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\<OrderItem> 컬렉션 필드**에 **@BatchSize(size=100)**&#xC774;에요!\
**xToOne 관계**인경우 **가장 상위 클래스에 @BatchSize 적용**\
(현업에서는 주로 전체 설정으로 많이 함.)
