1 인덱스와 힙

2 클러스터드 인덱스의 선택 문제

3 질의 적중률

Sparse Index와 Dense Index의 개념은 다음과 같다.

• Sparse Index:해당 레코드 존재 페이지를 가리키는 포인터를 저장
  
• Dense Index:해당 레코드를 가리키는 포인터를 저장
  
• Heap : 데이터가 입력되는 순서에 따라 정렬되어 쌓이는 테이블 구조
  
  

MS-SQL Server에서는 Sparse Index를 클러스터드 인덱스라고 부르고, Dense Index를 논클러스터드 인덱스라고 부른다. DB2(UDB), Oracle은 Dense Index만을 지원하고, MS-SQL Server, Sybase계열은 두 가지를 모두 지원한다. 구조상으로 기본구조는 Heap 또는 Dense Index로 구성되어야 한다. 구조상 그렇다. 여기에서는 MS-SQL Server를 다루도록 하것다. (자세한 인덱스에 대한 내용은 Index를 참고하기 바란다.)

그렇다면 클러스터드 인덱스(Sparse Index)와 논클러스터드 인덱스(Dense Index)를 어떤 기준으로 선정해야 할까? 아마도 MS나 Sybase의 DBMS를 만지고 있는 사람이라면 이런 고민 한 번쯤은 해봤을 것이다. 보통은 이렇다.

• 범위검색에 많이 사용된다면 클러스터드 인덱스를 사용
  
• 포인트쿼리(1건 검색)에 많이 사용되거나 몇 건 안되는 컬럼(들)에 논클러스터드 인덱스 사용
  
  

회원번호, 가입일..... 과 같은 테이블이라면 뭐 대충 날짜에 생성해 넣는다. 대충 맞기는 하다. 하지만 범위검색 조건으로 서로 다른 컬럼이 생성된다면 어떤 컬럼을 클러스터드 인덱스로 잡을 것인가? 애매모호하다. 대부분 이런 경우다. 주문일, 결제일, 배송완료일 중 어느 컬럼에 클러스터드 인덱스를 잡을 것인가??

주문테이블(주문번호, 회원번호, 주문일, 결제일, 배송완료일...)

물론 이전에 설계가 잘 되었는지 살펴보아야 한다. 많은 경우 설계상으로 해결할 수도 있다. 뭐.. 대충 다음과 같은 따위로 해결 할 수 있다. 바로 주문상태테이블의 상태변경일에 클러스터드 인덱스 잡으면 해결된다.

주문테이블(주문번호, 회원번호)
주문상태테이블(주문번호, 상태코드, 상태변경일) //상태코드: 1(주문), 2(결제), 3(배송완료)

뭐..이렇게 해결할 수도 있지만 어쨌든 통합을 하면 유연해지지만 데이터양이 늘어날 수도 있고, 개체집합의 개념의 범위가 늘어남에 따른 문제(개념의 범위가 조낸 넓으면 관리상의 문제와 데이터 품질에 문제가 생길 수 있다.)가 발생할 수도 있다. 어쨌든 주문일, 결제일, 배송완료일 중 어느 컬럼에 클러스터드 인덱스를 잡을 것인가??라는 문제는 여전히 애매모호하다. 애매모호한 이유가 뭘까? 2가지다.

• 클러스터드 인덱스는 테이블당 1개만 생성 가능하다.
  
• 범위검색 조건으로 여러 개의 컬럼이 독립적으로 자주 사용된다.
  
  

어쨌든 변하지 않는 사실은 클러스터드 인덱스는 테이블 1개만 생성 가능'이다. (딴지 걸지 말자. MS-SQL Server 2005의 인덱스 생성구문에 Inclued를 이용하면 2개의 클러스터드 인덱스 처럼의 흉내는 가능하지만 조낸 갱신부하 있다.) 어쨌든 클러스터드 인덱스를 생성할 컬럼을 선정해야 하기는 한다. 그렇다면 어떤 기준으로?? 바로, "질의적중률" 이다. 질의 적중률은 다음과 같이 계산된다. (초딩 산수다..)

질의적중률 = 검색Row수/전체Row수 

or 

질의적중률 = 논리IO수/전체IO --> 요거 추천...

위의 예를 들어 보면...

1. SUM(주문일로 검색되는 질의들의 질의적중률) 계산
   B. SUM(결제일로 검색되는 질의들의 질의적중률) 계산
   C. SUM(배송완료일로 검색되는 질의들의 질의적중률) 계산
   

IF      A > B AND A > C THEN A(주문일)에 클러스터드 인덱스 생성
ELSE IF B > A AND B > C THEN B(배송일)에 클러스터드 인덱스 생성
ELSE IF C > A AND C > B THEN C(배송완료일)에 클러스터드 인덱스 생성

끝이다. 조낸 간단하다. 결론은 질의적중률이 높은 컬럼(들)에 클러스터드 인덱스를 생성하면 유리하다.
요런게 왜 DBMS책에 안나오는 걸까?