mysql + java + JPA + querydsl 성능개선 관련 몇 가지 내용

메모 목적의 글로써 생략되는 내용이 많이 있을 수 있는점을 감안해주세요

(우아콘 2020참고)

 

1. querydsl exist 사용 금지
   1. 기본
      1. sql의 exist는 조건을 만족하는 1번째 row를 만나면 쿼리가 바로 종료
      2. count의 경우는 모든 row를 scan해야하기 때문에 성능이 exist보다 안 좋음
   2. qeurydsl의 exist는 count 쿼리를 이용해서 수행되기 때문에 성능이 안 좋음
   3. 직접 구현
      1. limit 1을 추가함(예전에 mysql 생쿼리로 개발할때도 이렇게 했었음..)
         1. 다만, 조회결과가 없으면 0이 아니라 null을 반환하니 null 체크처리 주의
2. cross join 회피
   1. 나올수 있는 모든 경우의 수를 대상으로 하기때문에 성능이 안좋은 cross join. 피하는게 좋음
   2. querydsl은 묵시적 join사용할때 cross join발생할 수 있음
   3. 명시적 join으로 회피
      1. 예) innerJoin 메소드로 명시적 처리
3. Entity 보다는 DTO를 우선 사용
   1. entity 조회시
      1. 실시간으로 Entity 변경이 필요한 경우에는 장점 -> 다만 회사 프로덕션 환경에서 이럴일은 없음
      2. hibernate 캐시 불필요
      3. 불필요한 컬럼 조회
      4. OneToOne N+1  쿼리 등
      5. 단순 조회 기능에서는 성능 이슈 요소가 많음
   2. DTO 조회시
      1. 고강도 성능 개선, 대량의 데이터 조회가 필요한 경우
      2. 조회 컬럼 최소화하기
         1. as 표현식으로 대체하면 DB에실행되는쿼리에서 as컬럼은 제외됨
            1. 예) Expressions.asNumber(bookNo).as("bookNo")
      3. Select 컬럼에 Entity 자제
         1. 불필요 신규 Entity의 모든 컬럼이 조회될 수 있음
         2. OntToOne 관계에 대해서 매건마다 조회됨(N+1무조건 발생하게 됨)
4. Group by 최적화
   1. mysql에서는 order by null 을 이용하면 file sort가 발생하지 않는 기능이 존재(개인적으로도 많이 사용)
   2. querydsl에서는 order by null을 지원하지 않기 때문에 직접 구현해서 사용
      1. 정렬이 필요하더라도 조회결과가 100건 이하라면 어플리케이션에서 정렬하는걸 고려(페이징이 아닐때만)
         1. was는 scale out이 가능하지만 DB는 어려움
5. 커버링 인덱스 사용
   1. 개인적으로도 대용량 게시판 서비스의 페이징 개념 만들때 사용함
   2. jpql은 from절의 서브쿼리를 지원하지 않기 때문에 우회처리가 필요
      1. 쿼리를 2개로 나눠서 실행
         1. Cluster Key(PK와 같은)를 커버링 인덱스로 빠르게 조회하고
         2. 조회된 Key로 select쿼리를 in 쿼리로 실행
6. update 최적화
   1. 무분별한 DirtyChecking을 꼭 확인해야함
      1. 실시간 비지니스 처리, 실시간 단건 처리시
         1. 하이버네이트 캐시는 일괄 업데이트시 캐시 갱신이 안되기때문에
      2. Querydsl.update
         1. 대량의 데이터를 일괄로 Update 처리시
7. bulk insert
   1. JPA에서는 auto_increment일때는 insert합치기가 적용되지 않는 문제가 있음
   2. jdbcTemplate롤 bulk insert는 처리 가능하나, 컴파일 체크, Type-safe 개발이 어려움
      1. 문자열로 쿼리를 작성해야해서
   3. 따로 개발해서 진행할수도 있지만... 개인적으로 고민좀 되는 부분이 있음