인덱스 종류

B-star Tree 인덱스

비트맵 인덱스

DISTINCT VALUE 개수가 적을 때 저장 효율이 매우 좋다.

• 카디널리티(NDV)가 낮은 컬럼
• ex) 성별, 지역코드, 상태코드 등

이런 컬럼이라면 B* Tree 인덱스보다 훨씬 적은 용량을 차지한다 인덱스가 여러개 필요한 대용량 테이블에 유용

다양한 분석관점 (Dimension) 을 가진 팩트 (Fact) 테이블이 여기에 속한다

여러 인덱스를 동시에 사용할 수 있다

• 여러개의 비트맵 인덱스로 Bitwise 연산을 수행하여 테이블 액세스량을 크게 줄일 수 있다면 극적인 성능 향상을 가져온다.
• 여러 조건을 조합한 임의 질의(ad-hoc query) 에서 비트 연산으로 빠르게 처리할 수 있어 성능 향상이 크다.
• 특히 대용량 데이터웨어하우스/OLAP 환경에서 유용하다.

다만 비트맵 인덱스는 DML(INSERT/UPDATE/DELETE) 부하가 크다,

• 레코드 하나만 변경되어도 해당 비트맵 범위에 속한 모든 레코드에에 락(lock)이 걸린다.
• 동시성이 중요한 OLTP 환경에는 부적합한 것이 단점이다.

함수기반(Function-Based) 인덱스

인덱스에도 함수를 적용한 상태로 값을 저장한 것

• 조건절에서 인덱스 컬럼에 함수를 적용하면 일반적으로 정상적인 Index Range Scan이 불가능하다.
• 인덱스는 “가공되지 않은 원본 값” 기준으로 정렬·저장되어 있는데, 가공한 값으로 검색하면 스캔 시작점/끝지점(범위)을 수직 탐색으로 결정할 수 없기 때문이다.
• 함수가 적용된 형태 그대로 값을 저장해 Range Scan이 가능하도록 만든 것이 함수 기반 인덱스(Function-Based Index)
• ex) CREATE INDEX 고객_FBI1 ON 고객 ( REPLACE(전화번호, '-', '') );

리버스키 (Reverse Key) 인덱스

• 변경일시, 일련번호처럼 값이 지속적으로 증가하는 컬럼에 대해 다수 트랜잭션이 동시에 INSERT를 수행하면 인덱스 맨 오른쪽(마지막) 리프 블록에 경합이 집중될 수 있다.
  • = Right Growing / Right-Hand Index
• 이를 완화하기 위해 인덱스 키 값을 뒤집어 저장하는 Reverse Key 인덱스를 사용한다.
  • 키 값이 뒤집히면 삽입 위치가 여러 리프 블록에 분산되어 리프 블록 경합이 감소한다.
• ex) CREATE INDEX HOT_TABLE_R1 ON HOT_TABLE ( RIGHT_GROWING_COL ) REVERSE;
• 함수 기반 인덱스로도 비슷한 효과를 낼 수 있으나, 그 경우 SQL 조건절도 REVERSE() 형태로 맞춰줘야 한다.