- 10장 - 인덱스 사용2024년 10월 04일
- 31514
- 작성자
- 2024.10.04.:05
RDB에서 사용하는 인덱스는 구조에 따라 다음과 같이 세 가지로 분류할 수 있다.
- B-tree 인덱스
- 비트맵 인덱스
- 해시 인덱스
B-tree 인덱스
데이터를 트리 구조로 저장하는 형태의 인덱스이다.
균형잡힌 뛰어난 범용성을 인정받아 가장 많이 사용된다.
사실 대부분의 데이터베이스는 트리의 리프 노드에만 키 값을 저장하는 B+tree를 채택한다.
B+tree는 B-tree에 비해 검색을 보다 효율적으로 만든 알고리즘이다.
하지만 본질적인 특징은 B-tree와 B+tree가 다르지 않다.
기타 인덱스
비트맵 인덱스는 데이터를 비트 플래그로 변환해서 저장하는 형태의 인덱스로, 카디널리티가 낮은 필드에 대해 효과를 발휘한다.
하지만 갱신할 때 오버헤드가 너무 크기 때문에 BI/DWH 용도로 사용된다.
해시 인덱스는 키를 해시 분산해서 등가 검색을 고속으로 실행하고자 만들어진 인덱스다.
하지만 범위 검색을 할 수 없다는 점 때문에 거의 사용되지 않는다.
카디널리티와 선택률
어떤 필드에 대해 인덱스를 작성할 것인지 기준이 되는 요소가 필드의 카디널리티와 선택률이다.
카디널리티란 값의 균형을 나타내는 개념인데, 카디널리티가 높으면 필드의 모든 레코드에 서로 다른 값이 들어가있는 유일 키 필드를 말한다.
선택률은 특정 조건을 사용하여 필터링했을 때, 전체 데이터에서 몇 개의 레코드가 선택되는지 비율로 나타내는 개념이다.
인덱스를 사용하는 것이 좋을 때
- 카디널리티가 높을 때 -> 특정 필드에 대해 중복되는 레코드가 거의 없을 때
- 선택률이 낮을 때 -> 조건을 사용하여 필터링했을 때, 적은 레코드가 선택될 때
인덱스로 성능 향상이 어려운 경우
<압축 조건이 존재하지 않은 경우>
select order_id, receive_date from orders;
레코드를 압축하는 WHERE 구가 애시당초 없다.
<레코드를 제대로 압축하지 못하는 경우>
select order_id, receive_date from orders where process_flg = '5';
1억 개의 레코드를 가진 orders 테이블에서 process_flg가 5인 레코드가 9,000만 건인 경우 선택률이 90%가 된다.
이런 경우 process_flg 필드에 인덱스를 만들면, 역효과가 발생할 수 있다.
<인덱스를 사용하지 않는 검색 조건>
- LIKE 연산자를 사용할 때, 중간 일치('%문자열%') 또는 후방 일치('%문자열')를 사용하는 경우
- 인덱스 필드로 좌변에 식을 사용하는 경우
select * from table where col_1 * 1.1 > 100;
- IS NULL을 사용하는 경우
- 인덱스 필드에 함수를 사용하는 경우
- 부정형을 사용하는 경우
인덱스를 사용할 수 없는 경우 대처법
<외부 설정으로 처리>
가장 간단한 해결방법은 처음부터 이러한 쿼리가 실행되지 않게 애플리케이션에서 제한하는 것이다.
예를 들어 사용자가 인덱스를 설정하기 적합한 조건을 필수적으로 입력하도록 제한하는 것이다.
<데이터 마트 사용하기>
데이터 마트는 특정한 쿼리에서 필요한 데이터만을 저장하는, 상대적으로 작은 테이블을 말한다.
데이터 웨어하우스에서는 데이터 마트가 접근 대상 테이블의 크기를 작게 해서 I/O 양을 줄이는 것을 목표로 사용된다.
데이터 마트를 사용할 때 다음과 같은 문제를 고려해야 한다.
- 데이터 마트와 원본 테이블의 동기 시점 -> 빈번한 갱신 처리는 성능 문제 유발
- 데이터 마트의 크기 -> 크기를 줄일 수 없는 경우 사용하지 않는 게 더 나음
- 데이터 마트 수 -> 사용되지 않는 데이터 마트 예방
- 배치 윈도우 압박
<인덱스 온리 스캔 사용>
SQL 구문이 접근하려는 대상의 I/O 감소를 목적으로 한다는 점에서는 데이터 마트와 동일하다.
특히 데이터 마트에서 문제가 되는 데이터 동기 문제를 해결할 수 있다.
CREATE INDEX CoveringIndex ON Orders (order_id, receive_date);
위와 같이 커버링 인덱스를 사용하여 데이터를 조회할 때, 테이블이 아닌 인덱스만을 스캔 대상으로 선정할 수 있다.
마치 필요한 필드만 지정해서 조회하는 방식과 유사하다.
따라서 선택률이 높은 필드에 대해 커버링 인덱스를 사용하면 좋은 결과를 가져올 수 있다.
'Book > SQL 레벨업' 카테고리의 다른 글
9장 - 갱신과 데이터 모델 (2) 2024.09.30 8장 - SQL의 순서 (0) 2024.09.27 7장 - 서브쿼리 (1) 2024.09.25 6장 - 결합 (0) 2024.09.24 5장 - 반복문 (0) 2024.09.23 다음글이전글이전 글이 없습니다.댓글