인덱스를 이용한 sort 연산 생략

인덱스 Range Scan이 가능하려면 가공하려는 컬럼의 데이터가 정렬되어 있어야 가능하다. 인덱스는 그렇기 때문에 정렬이 되어있다. 그래서 인덱스를 사용하는 이유가 있다. 

테이블 생성

create table sort_test (
id char,
ch_date date,
ch_order varchar(10));

제약조건 추가

ALTER TABLE SCOTT.SORT_TEST ADD CONSTRAINT ODER_PRIMARY PRIMARY KEY (ID,CH_DATE,CH_ORDER);

데이터

실행계획

PK를 기준으로 알아서 정렬이 되어있다. ( ID -> CH_DATE -> CH_ORDER 순서대로)

만약 별도로 order by를 sql에 지정한다고 해도 옵티마이저는 sort order by를 진행하지 않는다. 왜냐면 이미 pk 인덱스 생성시에 결과 집합에 대한 order by가 된 상태로 진행되기 때문이다.

만약 이렇게 정렬 연산을 생략가능하게 구성되어 있지 않다면 SORT ORDER BY가 추가 될 것이다.

인덱스에서 값을 찾을 때 인덱스 리프 블록에서 각 블록들은 더블 링크드 리스트로 연결되어있다. ASC 정렬인 경우에는 왼쪽에서 오른쪽 DESC인 경우에는 오른쪽에서 왼쪽으로 진행된다. 

각 DESC (내림차순)으로 사용하도록 쿼리를 작성하고 실행계획을 확인해도 별도의 SORT 작업은 진행하지 않는것을 알 수있다.

ORDER BY를 이용한 정렬 컬럼 가공
인덱스에서 사용되는 컬럼을 가공하면 INDEX가 타지 않는다고 알고있다. 근데 앞에서 살펴본 부분은 where조건에서 컬럼을 가공한 경우였다.

이번에는 인덱스에서 선언한 구조와 반대되는 쿼리를 짜보자. 위의 쿼리에서 PK 인덱스는 ID,CH_DATE,CH_ORDER 순서로 인덱스를 만들었다. 그렇기 때문에 ID -> CH_DATE -> CH_ORDER 순서로 정렬을 하면서 데이터를 찾는다.

하지만 다음과 같은 쿼리는 어떨까?

생성된 인덱스와 다른 기준으로 CH_DATE -> CH_ORDER 으로 정렬을 진행하였기 때문에 다시 정렬연산이 필요로 하게된다.

정리하면 인덱스 생성시에 sort가 되기 때문에 order by를 하여도 별도의 sort 연산을 하지 않는다.