4.포괄 인덱스

클러스터형 인덱스에 비한 넌클러스터형 인덱스의 단점은 인덱스 페이지에서 검색한 후 다시 데이터 페이지를 읽어야 한다는 점이다. 그래서 속도상 불리한 측면이 있고 특히 범위 검색은 손해가 막심하다. age 필드에 넌클러스터 인덱스가 걸린 상태에서 다음 쿼리문을 어떻게 실행할 것인가 생각해 보자.

SELECT addr FROM tArtist WHERE age = 33;

age 필드에 인덱스가 걸려 있으므로 이 조건에 맞는 레코드를 찾는 것은 쉽다. 그러나 필드 목록에서 주소를 요구했으므로 결국은 데이터 페이지를 찾아가 요구한 정보를 읽어야 한다. 포괄 인덱스는 넌클러스터 인덱스에 특정 필드를 같이 저장해 놓은 것이다. 인덱스 페이지에 원하는 정보를 같이 기록하므로 굳이 데이터 페이지를 읽지 않아도 상관없다. 다음 쿼리문으로 포괄 인덱스를 작성한다.

CREATE NONCLUSTERED INDEX Idx_artist_age ON tArtist(age) INCLUDE(addr);

INCLUDE 절에 인덱스 페이지에 같이 저장할 필드명을 밝힌다. 여러 개의 필드를 같이 저장할 수도 있다. 위와 같이 인덱스를 생성하면 인덱스 페이지에 정렬키인 age뿐만 아니라 주소 정보도 같이 저장한다.

이렇게 되면 인덱스에서 주소 정보를 바로 조사할 수 있어 클러스터형과 같은 속도를 낼 수 있다. 검색도 인덱스 페이지에서 할 수 있고 요구한 정보도 인덱스 페이지에서 바로 읽을 수 있다. 그러나 포괄하지 않은 필드를 읽을 때는 여전히 넌클러스터형 인덱스 방식으로 동작한다. 다음 쿼리문을 보자.

SELECT name FROM tArtist WHERE age = 33;

검색은 나이로 했고 필드 리스트에는 이름을 요구했는데 이름 필드는 인덱스 페이지에 기록해 놓지 않아 어쩔 수 없이 데이터 페이지를 또 뒤져야 한다. 이게 싫으면 name 필드도 인덱스 페이지안에 집어 넣어 버리면 된다. 이런 식이기 때문에 포괄 인덱스는 엄청난 공간을 소모하는 단점이 있다. 또 포괄한 필드를 수정할 때는 데이터 페이지뿐만 아니라 인덱스에 포함된 값도 같이 수정해야 한다.

포괄 인덱스를 나쁘게 평가하자면 약간의 속도 향상을 위해 대량의 메모리를 낭비하는 것이다. 한번 더 데이터 페이지를 찾아가는 것이 싫어서 아예 데이터 페이지를 인덱스에 넣어 버리는 무식한 기법이다. 이는 분명히 진실이며 위에서 보인 쿼리문은 포괄이나 넌클러스터나 거의 속도 차이가 없다. 하지만 포괄 인덱스가 정말 위력을 발휘할 때가 있다. 바로 다음과 같은 쿼리를 실행할 때이다.

SELECT addr FROM tArtist WHERE age BETWEEN 32 AND 36;

넌클러스터형 인덱스는 범위 검색에 취약하지만 포괄 인덱스는 넌클러스터형 인덱스로 클러스터형과 동일한 범위 검색 성능을 보인다. 검색 기준과 요구하는 정보가 모두 인덱스 페이지에 있어 굳이 데이터 페이지를 읽을 필요가 없다. 클러스터형 인덱스를 다른 컬럼에 이미 할당해 버린 상태에서 그 외의 컬럼에 대해 범위 검색을 자주 해야 한다면 이때는 포괄 인덱스가 좋은 해결책이다.

이상으로 인덱스의 내부 구조와 쿼리 실행시에 인덱스가 어떤 식으로 활용되는지 연구해 보았다. 도저히 이해하지 못할만큼 어렵지는 않지만 선뜻 이해가 될만큼 쉽지 않은 것도 사실이다. 그러나 너무 깊은 부분까지 이해할려고 노력할 필요는 없으며 다음 사실만 확실히 이해하고 있으면 된다.

인덱스는 검색 효율 향상에는 유리하지만 수정에는 불리하다.

이 명제만 이해한다면 인덱스를 언제 어떻게 활용해야 하는지 감잡을 수 있다. 실무에서 더 필요한 세부 사항은 그때 공부해도 늦지 않다.