데이터베이스 인덱스는 크게 Clustered Index와 Non-Clustered Index로 나뉜다.
두 인덱스는 “데이터를 어떻게 저장하고 접근하는가”에서 구조적인 차이가 있다.
이 차이를 이해하면 조회 성능, 인덱스 설계, 쿼리 최적화 방향이 명확해진다.
1. Clustered Index (클러스터드 인덱스)
Clustered Index는 테이블 데이터 자체가 인덱스 순서로 정렬되어 저장되는 구조다.
즉 인덱스와 실제 데이터가 하나로 묶여 있다.
InnoDB에서는 Primary Key가 Clustered Index로 사용된다.
CREATE TABLE post (
id INT PRIMARY KEY,
title VARCHAR(255),
content TEXT
);
이 경우 데이터는 id 기준으로 정렬된 상태로 저장된다.
따라서 PK 기반 조회는 매우 빠르게 동작한다.
특징
- 데이터 자체가 정렬되어 저장됨
- 테이블당 1개만 존재
- 범위 조회에 매우 유리
2. Non-Clustered Index (보조 인덱스)
Non-Clustered Index는 인덱스와 실제 데이터가 분리된 구조다.
인덱스에는 키 값과 함께 “데이터 위치(참조 값)”가 저장된다.
CREATE INDEX idx_title ON post(title);
이 인덱스를 사용하면 먼저 인덱스를 통해 PK를 찾고,
그 다음 Clustered Index를 통해 실제 데이터를 조회한다.
특징
- 데이터와 인덱스가 분리되어 있음
- 테이블당 여러 개 생성 가능
- 조회 시 추가 탐색이 발생
3. Clustered vs Non-Clustered 비교
| 구분 | Clustered Index | Non-Clustered Index |
|---|---|---|
| 데이터 저장 | 인덱스 = 데이터 | 인덱스와 데이터 분리 |
| 개수 | 1개만 가능 | 여러 개 가능 |
| 조회 속도 | 빠름 (직접 접근) | 한 번 더 탐색 필요 |
| 범위 검색 | 매우 효율적 | 상대적으로 비효율 |
| INSERT/UPDATE | 비용 큼 (정렬 유지) | 비용 상대적으로 적음 |
4. 왜 차이가 중요한가
Clustered Index는 물리적으로 정렬된 구조이기 때문에 범위 조회가 빠르다.
하지만 데이터 삽입 시 정렬을 유지해야 하므로 비용이 증가한다.
Non-Clustered Index는 여러 개를 만들 수 있어 다양한 조회 조건을 지원하지만,
조회 시 PK를 한 번 더 따라가야 한다는 비용이 있다.
5. 실무 설계 기준
- Primary Key는 정렬 가능하고 증가하는 값 사용 (AUTO_INCREMENT 권장)
- 조회가 많은 컬럼에 보조 인덱스 생성
- 불필요한 인덱스는 제거
- 복합 인덱스로 커버링 인덱스 고려
특히 PK가 랜덤 값(UUID 등)이면 페이지 분할이 자주 발생해 성능이 떨어질 수 있다.
가능하면 순차 증가 값이 유리하다.
6. 자주 발생하는 오해
인덱스를 많이 만들수록 좋은가
인덱스는 조회는 빠르게 하지만 쓰기 성능은 떨어뜨린다.
INSERT, UPDATE 시 모든 인덱스를 함께 갱신해야 하기 때문이다.
Non-Clustered Index도 항상 빠른가
보조 인덱스는 조건에 따라 오히려 느릴 수 있다.
특히 선택도가 낮으면 풀테이블 스캔이 더 빠른 경우도 있다.
한 줄 요약
Clustered Index는 데이터 자체를 정렬해 저장하는 구조이고, Non-Clustered Index는 데이터 위치를 참조하는 별도 구조다. PK는 Clustered, 나머지는 보조 인덱스로 설계하며 조회 패턴에 맞게 조합하는 것이 핵심이다.
댓글 0