클러스터드 인덱스란?

 

클러스터드 인덱스란?

(실제 사례들을 보며 개념 정리)

DB 인덱스를 공부하다 보면 클러스터드 인덱스(Clustered Index) 는 거의 빠지지 않고 등장한다.

막연히 “기본 키에 걸리는 인덱스”, “하나만 만들 수 있는 인덱스” 정도로 알고 있었는데,
여러 성능 튜닝 사례를 보다 보니 왜 중요한지, 왜 조심해서 선택해야 하는지가 조금씩 보이기 시작했다.

아직 이 문제를 직접 경험한 건 아니지만, 실제 운영 환경에서 자주 언급되는 개념이고

쿼리 튜닝을 해야한다면 알고는 있어야 할 것 같다.

그래서 정리해둘 필요가 있다고 느껴 글로 남겨본다.

---

클러스터드 인덱스란?

클러스터드 인덱스는 한 문장으로 정리하면 다음과 같다.

테이블의 실제 데이터가 인덱스 키 순서대로 정렬되어 저장되는 인덱스

일반적인 인덱스는

• 인덱스 따로
• 데이터 따로
  존재하는 경우가 많지만,

클러스터드 인덱스는
👉 데이터 자체가 인덱스 구조 안에 포함된다.

즉,

인덱스 리프 노드 = 실제 테이블 데이터

라는 점이 가장 큰 특징이다.

---

왜 “하나만” 만들 수 있을까?

여러 사례에서 항상 언급되는 특징이 있다.

클러스터드 인덱스는 테이블당 하나만 가능

이유는 단순하다.

• 데이터는 물리적으로 한 가지 기준으로만 정렬될 수 있기 때문이다.

예를 들어,

• id 기준으로 정렬하면서
• 동시에 created_at 기준으로도 정렬
  하는 건 불가능하다.

그래서 클러스터드 인덱스는
“이 테이블의 기본 정렬 기준은 무엇인가?” 를 결정하는 인덱스라고 볼 수 있다.

---

성능상 장점 (사례에서 자주 언급되는 부분)

1️⃣ 범위 조회에 매우 유리

SELECT *
FROM orders
WHERE order_date BETWEEN '2025-01-01' AND '2025-01-31';

• order_date 기준으로 클러스터드 인덱스가 있다면
• 실제 데이터도 날짜 순서로 저장됨
• → 연속된 데이터 블록만 읽으면 됨

그래서 대량 범위 조회가 많은 테이블에서는
클러스터드 인덱스가 큰 장점이 된다고 한다.

---

2️⃣ 정렬 비용 감소

SELECT *
FROM users
ORDER BY user_id;

• user_id가 클러스터드 인덱스라면
• 이미 정렬된 상태
• → 추가 정렬 작업이 필요 없음

이 부분도 실무 사례에서
“ORDER BY가 많은 쿼리에서 체감 성능 차이가 난다”는 이야기가 종종 나온다.

---

단점도 분명히 존재한다

사례들을 보면, 클러스터드 인덱스는 잘못 선택하면 오히려 독이 되기도 한다. (일반적인 인덱스도 같다.)

1️⃣ INSERT / UPDATE 비용 증가

• 중간 값 삽입
• 잦은 키 값 변경
  → 페이지 분할(Page Split) 발생 가능

데이터가 커질수록 이 비용이 점점 누적되어 성능 저하로 이어질 수 있다.

---

2️⃣ 키 선택이 매우 중요

자주 언급되는 안 좋은 예:

• 랜덤 UUID
• 값이 자주 변경되는 컬럼
• 길이가 긴 문자열 컬럼

이런 컬럼을 클러스터드 인덱스로 사용하면
데이터가 계속 흩어지고
성능 이점보다 관리 비용이 더 커질 수 있다.

---

논클러스터드 인덱스와의 차이

정리 차원에서 자주 비교되는 내용이다.

구분	클러스터드 인덱스	논 클러스터드 인덱스
데이터 저장	인덱스 키 순서로 실제 데이터 저장	인덱스와 데이터 분리
개수 제한	테이블당 1개	여러 개 가능
리프 노드	실제 데이터	데이터 위치 정보
범위 조회	매우 빠름	상대적으로 느림
키 변경 비용	큼	상대적으로 작음

여러 사례를 보면,
👉 “조회 패턴 중심”으로 클러스터드 인덱스를 결정하고
보조 인덱스로 논클러스터드 인덱스를 활용하는 방식이 일반적이다.

---

DBMS별 기본 동작 (간단 정리)

• MySQL (InnoDB)
  → 기본 키(PK)가 자동으로 클러스터드 인덱스
• SQL Server
  → 기본 키 생성 시 클러스터드 인덱스로 생성됨 (옵션 변경 가능)
• Oracle
  → 기본적으로 힙 테이블 구조
  → 클러스터드 인덱스 개념이 다소 다름

이 차이 때문에 DBMS별로 인덱스 설계 전략도 달라진다는 점이 흥미롭다.

---

정리하며

클러스터드 인덱스를 정리하면서 느낀 점은 다음과 같다.

• 클러스터드 인덱스는 단순한 인덱스가 아니라 데이터 저장 방식 그 자체
• “하나만 만들 수 있다”는 제약 때문에 처음 설계가 매우 중요
• 범위 조회·정렬이 많은 테이블에서는 강력한 무기가 될 수 있지만
  반대로 잘못 선택하면 지속적인 성능 저하의 원인이 될 수도 있음

아직 직접 문제를 겪은 건 아니지만, 실제 사례들을 보며 정리해보니
나중에 쿼리 튜닝에서 인덱스 설계를 고민할 때 반드시 떠올려야 할 개념이라는 생각이 들었다.