본문 바로가기
반응형

Performance16

Querydsl select에서 상수 사용하기 쿼리 성능을 개선할 수 있는 여러 방법 중에 가장 쉬운 방법은 조회하는 컬럼의 수를 최소화하는 것입니다. dzone-6-simple-performance-tips-sql 무분별하게 Entity를 가져오기 보다는 Dto로 필요한 필드만 가져오길 권장하는 이유이기도 한대요.(물론 Entity를 사용하지 않음으로 Hibernate 1차 캐시도 없다는 것도 주요 이유입니다.) 조회에 필요한 필드들만 조회하였지만, 그럼에도 더 줄일 수 있는 방법은 무엇이 있을까요? 가장 쉽게 해볼 수 있는 것이 이미 선언되어있는 값은 그대로 사용하는 것입니다. 메소드의 인자값으로 넘어왔거나, 다른 메소드를 통해서 이미 알고 있는 값을 굳이 DB에서 다시 조회해올 필욘 없겠죠? 그래서 이번 시간에는 Querydsl에서 상수를 사용.. 2020. 9. 3.
MySQL Update Subquery 성능 비교 (ver.5.6) 지난 포스팅으로 select ~ where in (서브쿼리)와 같은 서브쿼리가 MySQL 5.6 버전에서 대폭 최적화 되었음을 확인하였는데요. 이번에는 update (update ~ where in (서브쿼리)) 에서도 서브쿼리 최적화가 잘 작동하는지 확인해보겠습니다. 0. 테스트 환경 테스트 환경은 이전 select 테스트때와 같습니다. 메인 테이블 100만건 서브 테이블1 (인덱스 O) 1000건 서브 테이블2 (인덱스 X) 1000건 DDL 쿼리는 다음과 같습니다. 메인 테이블 -- 업데이트 대상 테이블 create table main_table ( id int not null auto_increment, target_id int not NULL, primary key (id) )ENGINE=Inn.. 2020. 9. 1.
MySQL where in (서브쿼리) vs 조인 조회 성능 비교 (5.5 vs 5.6) MySQL 5.5에서 5.6으로 업데이트가 되면서 서브쿼리(Subquery) 성능 개선이 많이 이루어졌습니다. 이번 시간에는 MySQL 2개의 버전 (5.5, 5.6) 에서 서브쿼리를 통한 조회 (Select)와 Join에서의 조회간의 성능 차이를 비교해보겠습니다. MySQL의 정석과도 같은 Real MySQL 책이 MySQL 5.5 버전을 기준으로 하다보니 5.6 변경분에 대해서 별도로 포스팅하게 되었습니다. 0. 테스트 환경 테스트용 테이블은 2개를 만들었습니다. 메인 테이블 100만건 서브 테이블1 (인덱스 O) 1000건 서브 테이블2 (인덱스 X) 1000건 DDL 쿼리는 다음과 같습니다. 메인 테이블 -- 업데이트 대상 테이블 create table main_table ( id int not .. 2020. 8. 27.
Querydsl Select 필드로 Entity 사용시 주의 사항 JPA 기반의 애플리케이션 개발에서 복잡한 조회가 필요할때는 Querydsl을 많이 사용합니다.아무래도 Querydsl로 추상화된 상태에서 쿼리를 작성하다보면 실제 어떻게 쿼리가 발생하는지 확인하지 않고 개발할때가 많습니다. 이를테면 쿼리 한번으로 해결하기 위해 select 필드에 Entity를 그대로 선언하는 경우가 바로 그런 경우인데요.(아래와 같은 쿼리일때입니다.) // customer는 Customer queryFactory .select(Projections.fields(EntityB.class, ... EntityA.EntityC) // EntityA의 EntityC 를 바로 선언 ) .from(EntityA) .where(..조건문..) .fetch() 위와 같이 쿼리를 작성하게 되면 Ent.. 2020. 8. 13.
JPA exists 쿼리 성능 개선 Spring Data Jpa를 사용하다보면 해당 조건의 데이터가 존재하는지 확인 하기 위해 exists 쿼리가 필요할때가 많습니다. 간단한 쿼리의 경우엔 아래와 같이 메소드로 쿼리를 만들어서 사용하는데요. boolean existsByName(String name); 조금이라도 복잡하게 되면 메소드명으로만 쿼리를 표현하기는 어렵습니다. 조건문이 3개 이상이거나, 필드명이 너무 길거나 조건문 자체가 복잡하는 등등 그래서 이런 경우엔 보통 @Query 를 사용하는데요. 다만 이럴 경우 JPQL에서 select의 exists 를 지원하지 않습니다. (select exists 문법) 단, where의 exists는 지원합니다. 그래서 exists 를 우회하기 위해 아래와 같이 count 쿼리를 사용합니다. @Q.. 2020. 8. 6.
2. 커버링 인덱스 (WHERE + ORDER BY / GROUP BY + ORDER BY ) 지난 시간에 이어 이번엔 ORDER BY에 대해 알아보겠습니다. 2-1. WHERE + ORDER BY 일반적으로 ORDER BY 의 인덱스 사용 방식은 GROUP BY와 유사합니다만, 한가지 차이점이 있습니다. 바로 정렬 기준입니다. MySQL에서는 인덱스 생성시 컬럼 마다 asc/desc 를 정할수 있는것 처럼 보입니다. (젯브레인사의 DataGrip으로 인덱스 생성시 가능한 것처럼 보입니다만… 안됩니다.) 하지만 8.0 이전 버전까지는 지원하지 않습니다. 8.0 이전 버전까지는 문법만 지원되고 실제로 Desc 인덱스가 지원되는 것은 아닙니다. 단지 Ascending index 으로 만들어진 인덱스를 앞에서부터 읽을 것인지 (Forward index scan), 뒤에서부터 읽을 것인지 (Backwar.. 2020. 2. 29.

728x90