개요
Clustered Index와 Non-Clustered Index는 데이터베이스에서 데이터를 빠르게 검색하기 위한 주요 인덱스 방식이다.
각 방식은 데이터가 저장되는 방식과 인덱스의 구성 방식에서 중요한 차이점이 있다.
Clustered Index
데이터가 실제로 저장되는 순서를 기반으로 하는 인덱스이다.
클러스터드 인덱스는 테이블의 데이터 자체가 인덱스의 순서대로 저장된다.
하나의 테이블에 대해 하나의 클러스터드 인덱스만 존재할 수 있다.
테이블의 데이터가 클러스터드 인덱스의 순서대로 정렬되어 저장된다.
예를 들어, 기본 키(PK)가 클러스터드 인덱스로 설정되면, 테이블의 데이터가 기본 키 순서대로 저장된다.
데이터를 실제로 저장하는 방식이 인덱스의 순서에 따라 결정되기 때문에 테이블당 하나만 존재할 수 있다.
범위 기반 쿼리(예: BETWEEN, >=, <= 등)에서 매우 효율적이다.
데이터가 물리적으로 정렬되어 있기 때문에 범위 검색을 빠르게 처리할 수 있다.
데이터가 인덱스 순서대로 물리적으로 저장되기 때문에, 인덱스를 이용한 데이터 접근이 빠르다.
데이터를 추가하거나 삭제할 때 클러스터드 인덱스 순서에 맞게 데이터를 이동해야 하므로 성능에 영향을 미칠 수 있다.
테이블당 하나의 클러스터드 인덱스만 가능하기 때문에, 다양한 인덱스를 필요로 하는 경우 다른 인덱스를 사용해야한다.
Non-Clustered Index
데이터의 물리적인 저장 순서와는 별개로 인덱스를 별도로 유지하는 방식이다.
이 인덱스는 인덱스 테이블 형태로 구성되며, 실제 데이터가 저장된 위치를 참조하는 포인터만 저장한다.
테이블은 클러스터드 인덱스를 사용하든 사용하지 않든 관계없이 여러 개의 논클러스터드 인덱스를 가질 수 있다.
특정 열에 대해 자주 검색을 수행하는 경우, 해당 열에 대해 논클러스터드 인덱스를 만들면 빠르게 검색할 수 있다.
클러스터드 인덱스와 달리 데이터가 물리적으로 정렬되지 않기 때문에 범위 기반 쿼리에서는 다소 비효율적일 수 있다.
예를 들어 고객 테이블이 존재한다고 가정해 보자, 고객 이름에 대해 논클러스터드 인덱스를 만든다면 이 인덱스는 고객 이름을 기준으로 정렬되어 있지만, 데이터는 다른 순서로 저장된다.
인덱스는 고객 이름을 찾고, 해당 이름의 데이터가 어디 있는지 알려주는 역할을 한다.
해당 테이블에서 여러 개의 논클러스터드 인덱스를 만들 수 있기 때문에 고객의 이름, 전화번호, 이메일에 대하여 각각 인덱스를 생성하고 참조할 수 있다는 장점이 있다.
또한 데이터의 저장 순서가 바뀌지 않기 때문에, 삽입, 삭제 및 업데이트가 상대적으로 빠르다는 장점이 있다.
다만, 데이터 자체를 저장하는 것이 아니라 인덱스를 저장하므로, 추가적인 저장 공간이 필요하다.
추가로, 데이터를 찾는 데 인덱스를 사용한 후, 실제 데이터를 찾기 위해 추가적인 작업이 필요하다.
요약
| 항목 | Clustered Index | Non-Clustered Index |
| 데이터 저장 순서 | 데이터가 인덱스 순서대로 저장됨 | 데이터는 인덱스 순서와 관계없이 인덱스 별도 존재 |
| 인덱스 수 | 테이블당 하나만 존재 | 테이블당 여러 개 존재 가능 |
| 범위 쿼리 성능 | 매우 효율적 (데이터가 정렬되어 있음) | 비효율적일 수 있음 (정렬되지 않음) |
| 검색 속도 | 빠르지만 범위 쿼리 외에는 상대적으로 덜 효율적 | 특정 컬럼에 대해 빠른 검색이 가능 |
| 공간 사용 | 공간 절약 (인덱스 크기가 작음) | 인덱스를 별도로 저장하므로 공간을 더 많이 사용 |
| 삽입/삭제 성능 | 삽입/삭제 시 데이터 재정렬로 성능 저하 가능 | 데이터 재정렬이 필요 없으므로 삽입/삭제 성능 상승 |
| 사용 예시 | 기본 키(primary key), 고유한 식별자가 필요한 열 | 자주 검색되는 열에 인덱스를 만들 때 유용 |