클러스터드 vs 논클러스터드 인덱스 개념 정리와 면접 질문

클러스터드 vs 논클러스터드 인덱스

핵심 차이

클러스터드 인덱스는 데이터 자체가 정렬된 순서로 저장됩니다.

페이지	담긴 행
Page 1	ID=1, 홍길동
Page 2	ID=2, 김철수
Page 3	ID=3, 이영희

정렬 순서가 곧 저장 순서이므로 테이블당 하나만 둘 수 있습니다. 사전과 같습니다.

논클러스터드 인덱스는 별도 인덱스가 데이터 위치를 가리킵니다.

인덱스 항목	가리키는 페이지
김	Page 3
이	Page 2
홍	Page 1

데이터는 저장 순서 그대로 두고 인덱스만 따로 두므로 테이블당 여러 개를 만들 수 있습니다. 책 뒤 색인과 같습니다.

비교

항목	클러스터드	논클러스터드
개수	테이블당 1개	여러 개 가능
데이터 정렬	물리적 정렬	별도 구조
범위 검색	매우 빠름	상대적 느림
삽입 성능	느림 (재정렬)	빠름
저장 공간	추가 없음	인덱스 공간 필요
비유	사전	책 뒤 색인

실무 선택 기준

범위 검색 많은 컬럼 (날짜, 가격)
  → 클러스터드 인덱스

정확한 값 조회 (이메일, 주문번호)
  → 논클러스터드 인덱스

자주 변경되는 컬럼
  → 클러스터드 피하기 (재정렬 비용)

MySQL vs PostgreSQL

DB	클러스터드 인덱스
MySQL (InnoDB)	PK가 자동 클러스터드
PostgreSQL	클러스터드 개념 없음 (CLUSTER 명령은 1회성)

면접 포인트

"PK를 AUTO_INCREMENT로 설정하는 이유가 뭔가요?"

InnoDB에서 PK = 클러스터드 인덱스. 순차 증가값이면 삽입 시 페이지 분할이 적어 쓰기 성능이 좋다. UUID를 PK로 쓰면 랜덤 삽입 → 페이지 분할 빈번 → 성능 저하.

항목	클러스터드	논클러스터드
데이터 배치	인덱스 순서대로 저장	별도로 저장. 인덱스는 위치를 가리킨다
개수	테이블당 하나	여러 개
조회	리프에 데이터가 있어 한 번에 끝난다	인덱스에서 위치를 찾고 데이터를 또 읽는다
범위 조회	매우 빠르다. 연속 저장이다	상대적으로 느리다
삽입	순서를 지켜야 해 비용이 있다	상대적으로 가볍다

항목

클러스터드

논클러스터드

데이터 배치

인덱스 순서대로 저장

별도로 저장. 인덱스는 위치를 가리킨다

개수

테이블당 하나

여러 개

조회

리프에 데이터가 있어 한 번에 끝난다

인덱스에서 위치를 찾고 데이터를 또 읽는다

범위 조회

매우 빠르다. 연속 저장이다

상대적으로 느리다

삽입

순서를 지켜야 해 비용이 있다

상대적으로 가볍다

문제	내용
페이지 분할	중간에 끼워 넣어야 해서 페이지를 쪼갠다
단편화	페이지에 빈 공간이 생겨 저장 공간이 늘어난다
캐시 효율 저하	삽입 지점이 흩어져 버퍼 풀 적중률이 떨어진다
보조 인덱스 비대	리프마다 16바이트 기본키가 들어간다. 정수의 두 배

문제

내용

페이지 분할

중간에 끼워 넣어야 해서 페이지를 쪼갠다

단편화

페이지에 빈 공간이 생겨 저장 공간이 늘어난다

캐시 효율 저하

삽입 지점이 흩어져 버퍼 풀 적중률이 떨어진다

보조 인덱스 비대

리프마다 16바이트 기본키가 들어간다. 정수의 두 배

클러스터드 인덱스는 데이터의 물리적 저장 순서 자체이기 때문입니다. 한 데이터를 두 순서로 동시에 저장할 수 없습니다.

이름 순으로 저장하면서 동시에 날짜 순으로 저장할 수는 없다

논클러스터드 인덱스는 데이터를 그대로 두고 위치만 가리키는 별도 구조라 여러 개를 만들 수 있습니다. 책 본문은 그대로 두고 색인을 주제별, 인명별로 여러 벌 만드는 것과 같습니다.

InnoDB 는 기본키를 클러스터드로 씁니다. 기본키를 지정하지 않으면 유일 인덱스를 쓰고, 그것도 없으면 내부 숨은 컬럼을 만듭니다.

흔한 실수: 클러스터드가 없는 테이블이 가능하다고 답하는 것. 엔진에 따라 다르며 InnoDB 는 항상 하나를 갖습니다. SQL Server 는 힙 테이블로 둘 수 있습니다.