인덱스

# 인덱스

- 검색을 잘하기 위함(효율적)

- select

- 테이블 전체 중 일부분만 참조

- 부가적

- 검색 키(search key) : 한 파일에서 레코드를 찾기 위한 속성이나 속성들의 집합(col, field)

- 주키, 후보키, 수퍼키와 다른 개념. where절에서 사용

- 하나의 테이블에 하나 이상의 검색키 존재 가능(여러 개 인덱스 존재 가능)

 

 

# 인덱스 레코드(엔트리)

검색키

포인터

- 포인터 : 검색키에 대한 한 개 이상의 레코드의 포인터

- 원본 파일 대비 크기 작음

- 포인터 구성: 디스크블록 ID(식별자), 블록 안에서의 해당 레코드의 offset

 

 

# 인덱스 종류

1. 순서 인덱스(Ordered Index)

- 검색 키 값에 대하여 정렬(순서화)

- 순차 순서

- B+ 트리 순서

 

2. 해시 인덱스(Hash Index)

- 검색키 값들이 여러 버킷들에 걸쳐 일정하게 분포

- 해시함수를 사용

- 빠른 접근, 시행 착오 없음

 

3. 비트맵 인덱스(Bitmap Index)

- 각 검색키 값 단위로 전체 레코드 개수만큼의 비트로 구성

- 여러 검색키들에 걸친 분석적 조회에 사용

 

 

# 인덱스 적용 시 고려 요소

1. 액세스 형태(Access Type)

- 검색키가 특정 값을 가지는 경우

- 검색키가 특정 범위를 가지는 경우

 

2. 액세스 시간(Access Time)

- 특정한 데이터(집합)을 찾는 시간

- 오버헤드 지불

 

3. 삽입 시간(Insertion Time)

- 데이터 항목 삽입을 위한 정확한 위치를 찾는 시간 + 인덱스 구조를 수정하는 시간

 

4. 삭제 시간(Deletion Time)

- 삭제할 항목을 찾는데 걸리는 시간 + 인덱스 구조를 수정하는데 걸리는 시간

 

5. 공간 부담(Space Overhead)

- 인덱스 구조를 운영함에 따른 부가적인 공간 부담

 

 

# 인덱스-순차 파일(Index-Sequential File)

- 데이터베이스 시스템에서 가장 오래된 인덱스 구조

- 주 인덱스를 가지는 파일

- ISAM 파일

 

 

# 다중 키 상의 인덱스

- 2개 이상의 속성으로 구성된 검색 키 : 다중 키(복합 검색키)

- 인덱스 구조는 동일

- 검색키 값이 복수 속성 값으로 구성됨(투플로 표현)

- 검색 키 순서 : 사전적 순서(알파벳 순서)

- a1 < b1 이거나 a1 == b1 이고 a2 < b2 이면  (a1, a2) < (b1, b2)

 

 

# 인덱스 자동 생성

- 릴레이션이 주 키를 가지면 주 키에 대한 인덱스 자동 생성(클러스터링 인덱스)

- 나중에 주 키 주면 성능 떨어짐

- 최초 테이블 만들 때 or 빈 테이블에 데이터 넣기 전 주 키 만들어줌

 

 

# 순서 인덱스(B+ 트리 인덱스)와 해시 인덱스 
- 범위 검색(클러스터링 인덱스에서만 좋음-주 키로 인덱스 구성. 비클러스터링은 안 좋음)
- = 인 경우 해시 인덱스가 좋음 
- 둘 다 분포도 높음(=하면 결과 개수 적음. unique) - OCTP(Read and Write) 

 

# 선택 시 고려 요소 
- 인덱스를 주기적으로 재구성하는데 소요되는 비용 
- 삽입과 삭제 빈도 
- 최악의 경우에 증가하는 액세스 시간을 감수하면서도 평균 액세스 시간을 최적화할 것인가 
- 사용자 질의 형태

 

 

# 비트맵 인덱스
- 분석을 하기 위함(결과가 완벽할 필요 없음. 추이. 제한적) - OCAP
- 비트들의 단순한 배열
- 다중 키를 가진 질의를 쉽게 하기 위함
- 릴레이션에 있는 레코드는 0부터 연속적인 번호를 가짐
- 레코드 수만큼 비트가 만들어짐
- 릴레이션의 크기와 비교하면 매우 작음
- 값의 분산도가 낮아야 함(값의 종류가 적음)
- bitwise operation연산이 제일 빠름(<<, >>)

 

 

# 비트맵 인덱스 동작 구조
1. 삭제 처리
- 존재 비트맵(Existence Bitmap) 사용
- 레코드 순서상에 유효한 레코드 존재 여부 표현
- 존재: 1, 부재: 0
- 비트맵 인덱스에 대한 연산 결과에 “AND ExistenceBitmap” 적용

2. 삽입 처리
- 삽입에 따른 비트맵 내용 전체에 변경을 가하는 것은 부담
- 해결
- 테이블의 맨 끝에 추가
- 삭제된 레코드 위치에 삽입

 

 

# SQL에서 인덱스 정의
- 순서 인덱스 생성
  create index <index-name> on <relation-name>(<attribute-list>)

  create index <index-name> on <relation-name>(<attribute-list>) 

  B+ 트리 인덱스 명시(디폴트)
  create index <index-name> on <relation-name>(<attribute-list>) using BTREE

  create index <index-name> on <relation-name>(<attribute-list>) using BTREE 

- 해시 인덱스 생성
  create index <index-name> on <relation-name>(<attribute-list>) using HASH

  create index <index-name> on <relation-name>(<attribute-list>) using HASH 

- 비트맵 인덱스 생성
  create bitmap index <index-name> on <relation-name>(<attribute-list>)

  create bitmap index <index-name> on <relation-name>(<attribute-list>) 

- 후보 키 생성(null 가능)
  create unique index <index-name> on <relation-name>(<attribute-list>)

  create unique index <index-name> on <relation-name>(<attribute-list>) 

- 인덱스 제거   

  drop index <index-name>

  drop index <index-name>