[ORACLE] 6. INDEX

B*Tree 인덱스

가장 자주 사용되는 일반적인 인덱스

이진 트리와 유사한 구조인 B*Tree Index는 Key값을 이용해서 개별적인 로우 또는 로우의 특정 범위를 빠르게 접근할 수 있도록 함

트리의 최하위 레벨 블록은 리프블록(leaf block) 이라고 불리는데, 모든 인덱스Key와 Rowid를 포함하고 있다.

내부 블록인 리프블록 위의 블록은 브랜치 블록(branch block)이라 함 인덱스 구조를 이동하는데 사용된다.

리프 블록에서 시작점을 찾은 다음 값의 정렬된 순서로 읽어나간다 = Index Range Scan 

 

B*Tree 인덱스 키 압축

복합컬럼(다수컬럼) 인덱스의 중복을 제거하는 것

모든 entry는 prefix + suffix 두 부분으로 나누어진다. prefix는 복합컬럼의 앞부분으로 중복되는 값이 많이 존재하는 부분이고 suffix는 키 컬럼의 뒷부분으로 같은 prefix 안에서 고유한 값을 가진다.

 

 

언제 B*Tree 인덱스를 사용해야 하는가 ? 

• 전체 테이블 로우 수에 비해 선택하려는 로우 수가 적은 경우

-> 테이블의 row에 접근하기 위해 전체에 비해 매우 적은 row를 접근할 수 있음

• 테이블의 많은 로우를 처리하지만 인덱스로만 처리가 가능한 경우

-> 인덱스가 쿼리에 응답하기 위한 충분한 내용이 있는 경우라서 테이블에 접근할 필요가 없음

• 테이블에 있는 모든 column의 row를 추출하기 위해

-> 전체 처리시간이 아닌 초기 반응 시간에 최적화 되어야 하는 경우

 

 

클러스터링 팩터 (Clustering Factor)

인덱스 값의 순서를 기준으로 테이블의 로우가 정렬된 정도 = 인텍스를 사용하여 전체 테이블 스캔을 수행했을 때 발생하는 논리 I/O 숫자

이 값이 블록 갯수와 가깝다면 테이블은 인덱스 순서로 잘 정렬되어 있다는 의미.

이 값이 로우 갯수와 가깝다면 테이블은 랜덤하게 저장되어 있다는 의미

 

 

비트맵 인덱스

하나의 인덱스 키 entry에 많은 row에 대한 포인터를 저장하고 있는 구조

 

언제 비트맵 인덱스를 사용해야 하는가 ? 

• 낮은 카디널리티 데이터 = 전체 데이터에 비해 종류가 적은

-> 선택도가 높아야함. 예를 들어 젠더같은 남/녀/null 등으로 전체 row에 대비해 종류가 적은 컬럼들

• read가 많은 환경 = write가 많은 환경엔 안좋음

-> 하나의 인덱스 키가 많은 row를 가리켜서 하나의 세션이 인덱스 엔트리를 수정하게되면 (Write) 그 인덱스가 포인터하고 있는 모든 row를 lock 걸기 때문

 

 

비트맵 조인 인덱스

다른 테이블의 컬럼을 이용한 인덱싱이 가능하도록 함

인덱스를 만들 때 두 개 이상의 테이블 조인을 사용하여 생성하는데, 조인 조건은 다른 테이블의 PK, UK 조인을 포함해야 함

 

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

계산된 컬럼에 인덱스를 생성하여 쿼리에서 이 인덱스를 사용하는 것.