반응형

❏ 인덱스 특징과 종류

 

 - 인덱스는 원하는 데이터를 쉽게 찾을 수 있도록 돕는 책의 찾아보기와 유사한 개념이다. 목적은 검색 성능의 최적화 이다.   

    DML 작업은 테이블과 함께 인덱스도 같이 변경해야 하기 때문에 오히려 느려질 수도 있다는 단점이 있다. (따라오기 때문에)

   

 

 

❏ 트리 기반 인덱스

 

 - 가장 일반적인 인덱스는 B-트리 인덱스 이다.

 

 

 

Root Block : 대장

Branch Block : 분기를 목적으로 한다. 다음 단계의 블록을 가리키는 포인터를 가지고 있다.

Leaf Block  : 제일 말단

 

Leaf Block 은 인덱스를 구성하는 칼럼의 데이터와 위치를 가리키는 식별자(RID, Record Identifier/Rowid) 로 구성되어 있다

 

인덱스 데이터는 인덱스를 구성하는 칼럼의 값으로 정렬된다

만약 인덱스 데이터의 값이 동일하면 레코드 식별자의 순서로 저장된다

 

Leaf Block 은 양방향 링크를 가지고 있다. 오름/내림 차순 검색을 쉽게 할 수 있고, =, BETWEEN, >, 등과 같은 검색에도 적합하다

 

 

 

브랜치 블록이 3개의 포인터(3 방향 말하는듯)로 구성된 B-트리 의 인덱스의 예이다. 인덱스에서 원하는 값을 찾는 과정은 다음과 같다

 

1> 브랜치 블록의 가장 왼쪽 값이 찾고자 하는 값보다 작거나 같으면 왼쪽 포인터로 이동

2> 찾고자 하는 값이 브랜치 블록의 값 사이에 존재하면 가운데 포인터로 이동

3> 오른쪽에 있는 값보다 크면 오른쪽 포인터로 이동 (초과 말하는거같은데)

 

과정을 반복하다가 존재 하면 찾은것이고, 없으면 해당값이 존재하지 않아 검색에 실패한 것이다.

 

 

37을 찾아보자.

 

루트 에서 왼쪽 값 (50) 이랑 비교 해봤는데 작다.  왼쪽 포인터로 이동하자

 

11에 대봤는데 크다. 11~40 에 해당하니 중앙 포인터로 이동하자.

 

37이 있네.

 

찾았다

 

BETWEEN 37 AND 50 을 해보면

 

37을 먼저 찾고 50 보다 큰 값을 만날때 까지(50이 끝이니까) 하나씩 오른쪽으로 이동하면서 읽는다.

 

인덱스 데이터가 정렬 되있고 양방향 링크로 연결되있으니까 가능한 일이다.

 

트리기반 인덱스 종류 : B-트리 인덱스, 비트맵 인덱스, 리버스 키 인덱스, 함수기반 인덱스 등이 존재한다.

 

 

 

 

❏ SQL SERVER 의 클러스터형 인덱스

 

 - SQL SERVER 의 인덱스 종류는 클러스터형 / 비클러스트형 인덱스로 나뉜다. 

   

   클러스터형 인덱스의 두가지 특징

   1. LEAF 페이지가 곧 데이터 페이지이다. 즉 테이블 탐색에 필요한 레코드 식별자(rowid 같은거) 가 LEAF 페이지에 없다.

      원래 LEAF 페이지에서 하나 더 내려갔었는데...

 

   2. LEAF 페이지의 모든 데이터는 인덱스 키 칼럼 순으로 물리적으로 정렬되어 저장된다.

      한가지 순서로만 정렬될 수 있다. 전화번호부 한 권을 상호와 인명으로 동시에 정렬할 수 없는것 같이..

 

 

 

 

 

 

❏ 전체 테이블 스캔

 

 - 테이블에 존재하는 모든 데이터를 읽어 가면서 조건에 맞으면 결과로 빼고 안맞으면 버리고.. 끝까지..

 

 

HWM ( High Water Mark ) 아래의 모든 블록을 읽는다.

HWM 이란, 테이블에 데이터가 쓰여졌던 블록 의 최상위 위치. (지금은 있는지 없는지 는 모른다. 단순히 위치니까) 

 

옵티마이저( 최적의 방법을 선택하는 애 ) 가 왜 전체 테이블 스캔을 선택하는 경우가 있을까? 언제 이런 방법을 선택할까

 

1. SQL 문에 조건이 존재하지 않는 경우 

  - 뭐.. 조건 없으면 다 읽어야지..;

2. SQL 문의 주어진 조건에 사용 가능한 인덱스가 존재하지 않는 경우

  - 조건이 있긴 해도.. 인덱스가 없으면 모든 데이터를 읽어가면서 주어진 조건에 맞는지 검사하면서 다녀야한다.

    (조건도 있고 인덱스도 있는데 함수를 사용하여 인덱스 칼럼을 변형한 경우에도 인덱스를 사용할 수 없다..)

3. 옵티마이저의 취사 선택

  - 조건을 만족 하는 데이터가 많은경우.. 그냥 많은게 아니라 테이블의 대부분을 스캔해야될거같애.. 

4. 그 밖의 경우

  - 벙렬 처리 방식으로 처리하는 경우 또는 전체 테이블 스캔 방식의 힌트 (?) 를 사용한 경우

 

 

 

 

❏ 인덱스 스캔 (트리기반)

 

 - 인덱스를 구성하는 칼럼의 값을 기반으로 데이터를 추출한다

 - 인덱스의 LEAF 블록은 인덱스를 구성하는 칼럼, 레코드 식별자로 구성되어 있다.

 - SQL 문에서 필요로 하는 모든 칼럼이 인덱스 구성 칼럼에 포함된 경우 테이블에 대한 액세스는 발생하지 않는다. 

 - 인덱스는 인덱스 구성 칼럼의 순서로 정렬되어 있다. 

 

 

인덱스 유일 스캔 (Index Unique Scan)

  유일 인덱스 (Unique Index) 를 사용하여 단 하나의 데이터를 추출하는 방식.

  중복을 허락하지 않고, 구성 칼럼은 모두 = 로 구성되어야 한다. 결과는 최대 1건.

  한 값 찾을때.

 

인덱스 범위 스캔 (Index Range Scan)

  인덱스를 이용하여 한 건 이상의 데이터를 추출하는 방식.

  인덱스의 구성 칼럼 모두에 대해 = 로 값이 주어지지 않은 경우와

  비유일 인덱스 를 이용하는 모든 액세스 방식이 해당한다.

  아래의 왼쪽 그림에 해당한다. 범위 스캔 정방향 은 이거 아까 BETWEEN 떠올리면 된다.

 

 

인덱스 역순 범위 스캔 (Index Range Scan Descending)

  오른쪽 그림 처럼 인덱스의 LEAF 블록에서 오름차순이 아니라, 내림차순으로 데이터를 읽는 방식이다.

  똑같이 BETWEEN 그거 떠올리는데. 방향이 내림차순 으로 간다는 것이다. 처음 가는게 최대값이니. 최대값 찾기엔 쉽다.

 

 

이 외에도 인덱스 전체 스캔, 인덱스 고속 전체 스캔, 인덱스 스킵 스캔 등이 있다.

 

 

 

 

❏ 전체 테이블 스캔과 인덱스 스캔 방식의 비교

 

 - 대용량 데이터 중 극히 일부의 데이터를 찾을 때는 인덱스 스캔 방식으로 몇번의 I/O 만으로 찾는게 좋고

   

   한번에 여러 블록씩 읽을 때는 모든 데이터를 읽으면서 원하는 데이터를 찾는 전체 테이블 스캔이 좋다.

 

 

 

 

반응형
도움이 되셨다면 공감 클릭 부탁드리며
출처만 남겨주시면 글 내용은 마음껏 퍼가셔도 좋습니다 :)