https://www.youtube.com/watch?v=zMAX7g6rO_Y&t=3s

요약

SELECT

1. Querydsl에서 exist 사용 금지
2. Cross Join 회피하라
3. Entity 보다 Dto를 우선하라
   1. 조회 컬럼 최소화
   2. Select 컬럼에 엔티티 자제
4. Group By 최적화 (order by null)
5. 커버링 인덱스

UPDATE / INSERT

1. 일괄 Update 최적화 (벌크연산)
2. Bulk Insert는 JPA로는 자제하라

Select 최적화

1. Querydsl에서 exist 사용 금지

   • 사유
     • SQL 문에서는 exist가 count 쿼리보다 훨씬 성능이 좋다
       • exist는 존재여부만 체크하는 반에 count 쿼리는 모든 컬럼을 확인해야함
     • 그러나 Querydsl에서 exist는 count()>0 으로 실행된다
     • JPQL은 from 없이는 쿼리를 생성할 수 없음으로 SQL 문의 exist 기능을 사용할 수 없다
   • 대안
     • imit 1로 조회 제한 (fetchFirst())
       • fetchFirst() == limit(1).fetchOne();
       • 주의! 만약 값이 없다면 0이아닌 null이 반환됨으로 Integer로 리턴값을 받고 null인지 아닌지로 체크해야한다

2. Cross Join 회피하라

   .where(customer.customNo.gt(shop.shopNo))
   

   • 묵시적 Join 사용시 cross join
   • 이는 hibernate 이슈로 querydsl 여부와 무관하게 spring data jpa도 발생할 수 있다
   • 대안

     • 명시적 join 사용

       .innerJoin(customer.shop, shop)
       .where(customer.customNo.gt(shop.shopNo))
       

3. Entity 보다 Dto를 우선하라

   • 단순조회에서는 Entity로 조회하는 것이 성능 이슈 요소가 많다
     • 불필요한 컬럼 조회, OneToOne N+1 쿼리 문제등
   • 대안

     1. 조회 컬럼 최소화

        • 이미 알고 있는 값들에 대해서 as 표현식으로 대체
        • select 절에서 제외된다

        public List<BookPageDto> getBooks(int bookNo, int pageNo){
        return queryFactory
        	.select(Projections.fields(BookPageDto.class,
        		book.name,
        		Expression.asNumber(bookNo).as("bookNo"),
        		book.id))
        	.from(book) ...
        }
        

   1. Select 컬럼에 엔티티 자제

      • 엔티티에 다른 엔티티가 연관되어있다면, 해당 엔티티의 모든 컬럼이 다 조회되어버림

      • oneToOne은 LazyLoading이 안된다 > N+1 문제

      • 또한 distinct 대상이 entity 컬럼 전체가 되어 최적화에 악영향을 끼친다

      • 엔티티 연관관계를 맺기 위해서 반대 엔티티도 필요하지 않은가?

        • 연관된 엔티티의 save를 위해서는 반대편 엔티티의 id만 필요하다

        

        

4. Group By 최적화

   • MySQL에서 GroupBy를 사용하면 FileSort가 빈번하게 발생
     • FileSort란?
       • MySQL 정렬은 인덱싱과 FileSort로 나누어진다
       • MySql이 인덱싱을 사용하지 못할 때 사용하는 정렬 방법
       • 드라이빙 테이블(sortbuffer 사용)
         • "Using temporary”
         • 조회되는 테이블 중 먼저 액세스 되는 테이블만 sortbuffer에서 정렬하여 나머지 테이블과 조합
       • 임시 테이블 정렬 (2개 이상의 테이블을 조인해서 그 결과를 전부 임시 테이블에 넣어서 정렬)
         • "Using temporary, Using filesort”
         • 제일 느림, 임시 테이블이 디스크에 저장되면서 치명적 I/O 부하
         • 이 경우는 WAS 단에서 정렬하는 것을 추천
   • order by null? :
     • ORDER BY NULL : 특정 컬럼의 정렬을 NULL 값으로 강제로 설정하는 방법
     • filesort를 막을 수 있다
     • 페이징의 경우, order by null 사용 불가
   • WAS 자원 < DB 자원
     • 따라서 Record 개수가 많아면 WAS 단에서 정렬하는 것을 추천한다

5. 커버링 인덱스

   • 쿼리를 충족하는데 필요한 모든 컬럼을 가지고 있는 인덱스
   • select / where / order by / group by 등에 사용되는 모든 컬럼이 인덱스에 포함된 상태
   • 페이징 조회 성능 향상에 가장 보편적인 방법 with NoOffset
   • 아래의 예시에서 join 문 안의 절이 커버링 인덱스

   select *
   from academy a
   join (select id
   		from academy
   		order by id
   		limit 10000, 10) as temp
   on temp.id = a.id
   

   • 그러나 JPQL에서는 from 절에 서브쿼리를 지원하지 않는다

   • 대안

     • 클러스터 키(PK)를 커버링 인덱스를 따로 생성하여 조회
     • 조회된 key들로 select 컬럼들을 후속 조회한다

     

Update/Insert 최적화

1. 일괄 Update 최적화 (벌크연산)

   • DirtyChecking vs Querydsl.update

     • 모든 컬럼을 돌면서 update해야 하는 dirty checking

     • 한번에 update by querydsl의 성능!!

       queryFactory.update(student).where(student.id.loe(studentId))
       	.set(student.name, name)
       	.execute(); // 벌크 연산시 사용
       

   • 단점으로 일괄 업데이트시에 하이버네이트 캐시 갱신이 안됨

2. Bulk Insert는 JPA로는 자제하라

Querydsl