본문 바로가기

MySQL16

2. 페이징 성능 개선하기 - 커버링 인덱스 사용하기 2. 커버링 인덱스 사용하기 앞서 1번글 처럼 No Offset 방식으로 개선할 수 있다면 정말 좋겠지만, NoOffset 페이징을 사용할 수 없는 상황이라면 커버링 인덱스로 성능을 개선할 수 있습니다. 커버링 인덱스란 쿼리를 충족시키는 데 필요한 모든 데이터를 갖고 있는 인덱스를 이야기합니다. 즉, select, where, order by, limit, group by 등에서 사용되는 모든 컬럼이 Index 컬럼안에 다 포함된 경우인데요. 여기서 하나의 의문이 드는 것은 select절까지 포함하게 되면 너무 많은 컬럼이 인덱스에 포함되지 않겠냐는 것인데요. 그래서 실제로 커버링 인덱스를 태우는 부분은 select를 제외한 나머지만 우선으로 수행합니다. 예를 들어 아래와 같은 페이징 쿼리를 SELECT.. 2020. 10. 24.
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.
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.
Querydsl 에서 Group by 최적화하기 (feat. MySQL) 1. MySQL에선 Group by를 하면 정렬도 수행된다고? 일반적으로 MySQL 에서 Group By를 실행하면 file sort가 필수로 들어갑니다. 별도의 Order by가 쿼리에 포함되지 않았음에도 file sort가 발생하는 것이죠. Group by 실행시 해당 컬럼들을 기준으로 정렬이 되니 좋아보일수 있겠지만, 의도치 않게 성능 저하가 발생하는 이유가 되기도 합니다. 물론 인덱스에 있는 컬럼들로 Group by를 한다면 큰 문제가 되지 않습니다. 인덱스로 인해서 이미 컬럼들이 정렬된 상태이기 때문입니다. 정렬이 필요 없는 Group by 된 결과가 필요한 경우엔 굳이 정렬할 필요가 없겠죠? 이 문제를 해결하는 방법이 바로 order by null 입니다. 아래와 같이 order by null.. 2020. 2. 21.
1. 커버링 인덱스 (기본 지식 / WHERE / GROUP BY) 일반적으로 인덱스를 설계한다고하면 WHERE절에 대한 인덱스 설계를 이야기하지만 사실 WHERE뿐만 아니라 쿼리 전체에 대해 인덱스 설계가 필요합니다. 인덱스의 전반적인 내용은 이전 포스팅을 참고하시면 좋습니다. 인덱스는 데이터를 효율적으로 찾는 방법이지만, MySQL의 경우 인덱스안에 포함된 데이터를 사용할 수 있으므로 이를 잘 활용한다면 실제 데이터까지 접근할 필요가 전혀 없습니다. 이처럼 쿼리를 충족시키는 데 필요한 모든 데이터를 갖고 있는 인덱스를 커버링 인덱스 (Covering Index 혹은 Covered Index) 라고합니다. 좀 더 쉽게 말씀드리면 SELECT, WHERE, ORDER BY, GROUP BY 등에 사용되는 모든 컬럼이 인덱스의 구성요소인 경우를 얘기합니다. 1-1. 커버링.. 2020. 2. 16.