티스토리 뷰

1. Clustered Index만 존재했을 때
CI의 정렬 기준으로 실제 데이터를 정렬해 둡니다. 데이터를 찾을 때 CI를 타느냐, 테이블 스캔 하느냐의 차이만 존재합니다. 

1-2. 구조
루트페이지와 리프페이지의 2중 구조

루트페이지에는  검색기준이  리프페이지에는 실제 데이터가 검색기준에 맞쳐 분류되어있음

쿼리시  루트 페이지에서 해당 검색기준을 통해 리프페이지(실제데이터)를 검색하여 결과처리

데이터 변경작업시 루트페이지에 맞쳐서  리프페이지를 다시 분류작업함

2.
Non-Clustered Index만 존재했을 때

이 경우 NI의 키 값 대로 정렬된 데이터가 존재하고, 키 값에 대응하는 실제 데이터의 주소 (파일, 페이지, 행번호) 를 가집니다.

NI에서의 키 값에 매칭되는 값을 찾은 후, 실제 데이터를 찾아가는 과정만큼의 비용이 필요합니다.
이 비용이 크기 때문에, 일반적으로 NI를 이용해서 찾는 데이터가 전체 데이터의 3~5%이내 일 때만 NI를 이용하고, 그렇지 아닐 경우 테이블 스캔을 합니다.

2-1. 구조
루트페이지와 리프페이지. 실제데이터의 3중구조.

루트페이지에는 검색기준, 리프레이지에는 실제데이터를 참조한 분류 ,실제데이터에는 데이터

select 시에는 3중구조임으로 클러스터형 인텍스보다 비효율적임

그러나. 데이터 변경작업시에는 실제데이터에는 변경이 없음으로 클러스터형 보다 효율적.

3. Non-Clustered Index와 Clustered Index 공존시

이 경우 NI가 실제 데이터의 행번호를 가리키는 것이 아니라, CI의 키 값을 가리킵니다.

장점은 CI가 변경될 때, NI에 적은 영향을 줍니다. (CI로 정렬 되어 있는 만큼, 테이블 중간에 데이터가 끼어들거나 삭제되면 페이지 분할등이 일어나 행번호가 바뀔여지가 있습니다. 행번호가 바뀌어도 행번호가 아니라, CI의 키 값을 가리키기 때문에 NI에 적은 영향만을 주고 데이터를 변경할 수 있게 됩니다.)

3-1. 구조
루트페이지(비클러스터형)  -> 리프페이지 (비클러스터형) ->  루트페이지 (클러스트형) -> 리프페이지 (클러스트형) 의 4중구조 (실제데이터는 리프페이지 - 클러스트형)

댓글