데이터베이스에서 사용되는 인덱스(Index)에 대해 알아보겠습니다.

Ⅰ. 인덱스(Index) 란?

 데이터베이스에서 인덱스(Index)는 테이블에서 원하는 데이터를 더 빨리 찾기 위해 만드는 “검색용 구조”입니다. 책으로 비유하면 테이블이 책의 본문이고, 인덱스는 목차나 찾아보기 역할을 합니다. 본문을 처음부터 끝까지 훑지 않아도, 목차를 통해 원하는 페이지로 바로 이동하는 것처럼 사용됩니다.
 대부분의 DBMS는 인덱스를 만들 때  B-Tree 또는 B + -Tree 같은 정렬 기반 자료구조를 사용합니다. 그래서 인덱스가 있으면 “특정 값 검색”뿐 아니라 “범위 검색(예: 1월~3월)”도 효율적으로 처리할 수 있습니다.

Ⅱ. 인덱스(Index) 흐름

인덱스가 B-Tree 구조로 저장될 때, 각 단계에서 쓰는 페이지(노드)를 말합니다. 인덱스 탐색은 보통 Root에서 시작해서 Intermediate를 거쳐 Leaf까지 내려가는 흐름입니다

 

 ⅰ. Root Page (최상단 페이지)
 인덱스 트리의 맨 위(최상위) 페이지(노드)입니다. 여기에는 “어느 범위의 키 값은 아래 어떤 페이지로 내려가라” 같은 하위 페이지 안내 정보(키 값 + 포인터)가 들어갑니다.
​ ⅱ. Intermediate Page (중간/브랜치 페이지)
 Root와 Leaf 사이에서 탐색 경로를 더 잘게 나눠주는 중간 단계입니다. 인덱스 크기가 작으면 중간 단계가 없어서 Root 아래에 Leaf가 바로 붙을 수도 있습니다.
 ⅲ. Leaf Page(최하단 페이지)
 “Leaf에 실제 데이터(Row)가 있냐”는 인덱스 종류에 따라 달라집니다.
​  1) 클러스터 인덱스: Leaf Page가 곧 실제 데이터(Row) 페이지(= 테이블 데이터)인 구조로 설명됩니다.
​  2) 논 클러스터 인덱스: Leaf Page에는 실제 Row가 아니라, Row를 찾기 위한 위치 정보(포인터)가 있고 실제 데이터는 별도 데이터 페이지에 있습니다

Ⅲ. 클러스터 인덱스(Clustered Index)

ⅰ.  클러스터 인덱스(Clustered Index) 란?

테이블의 실제 데이터(Row)가 인덱스 키 순서대로 정렬된 상태로 저장되는 방식입니다. 즉 “인덱스 따로, 데이터 따로”가 아니라, 데이터 자체가 인덱스의 리프(Leaf)에 붙어 있는 구조라고 이해하면 쉽습니다.

 

여기서 핵심은 Leaf Page에 진짜 데이터가 들어 있다는 점입니다. 그래서 클러스터 인덱스를 타고 Leaf까지 내려가면 추가 작업 없이 바로 결과 Row를 가져올 수 있습니다.

 ⅱ. 클러스터 인덱스(Clustered Index) 동작 예시

SELECT * FROM orders WHERE order_id = 100; 인덱스(B-Tree) 탐색 → Leaf 도달 → Row 반환(추가 조회 거의 없음)

 ⅲ. 클러스터 인덱스(Clustered Index) 장점
   1) 범위 조회(Range Scan)에 강함 (정렬된 데이터가 그대로 이어져 있음)
   2) ORDER BY, GROUP BY 같은 정렬/그룹 작업에 유리한 경우가 많음
   3) 불필요한 I/O를 줄이기 쉬움

 

 ⅳ. 클러스터 인덱스(Clustered Index) 단점
   1) INSERT/UPDATE 시 “정렬 상태”를 유지해야 해서 비용이 커질 수 있음
   2) 중간에 끼워 넣는 데이터가 많으면 페이지 분할(Page Split)이 발생할 수 있음
   3) 테이블당 1개만 가능(데이터 정렬 기준은 하나뿐)

 

 ⅴ. 클러스터 인덱스(Clustered Index) 사용하기 좋은 경우
   1) PK(Primary Key)처럼 대표 키가 명확한 테이블
   2) 날짜, ID처럼 값이 순차 증가하는 컬럼
   3) 범위 조건 조회가 잦은 컬럼(예: 기간 조회)

Ⅳ.  논 클러스터 인덱스(Non-Clustered Index)

 ⅰ. 논 클러스터 인덱스 (Non-Clustered Index) 란?

 인덱스와 실제 데이터가 분리되어 있습니다. 인덱스의 Leaf에는 “데이터 그 자체”가 아니라, 데이터를 찾기 위한 포인터(위치 정보)가 저장됩니다. “목차는 있는데 본문은 다른 곳에 있고, 목차가 본문 위치를 알려주는” 형태입니다.
Leaf에 실제 데이터가 없기 때문에, 인덱스로 조건을 찾은 뒤에도 데이터 페이지를 한 번 더 찾아가야 하는 경우가 많습니다. 이 추가 동작을 보통 Key Lookup(또는 Bookmark Lookup)이라고 부릅니다.

 

 ⅱ. 논 클러스터 인덱스 (Non-Clustered Index) 동작 예시

SELECT name FROM users WHERE email = 'a@b.com'; 논 클러스터 인덱스 탐색 → Leaf에서 Row Pointer 획득 → 실제 데이터 페이지 접근(Key Lookup) 후 필요한 컬럼 읽음

 ⅲ. 논 클러스터 인덱스 (Non-Clustered Index) 장점
   1) 테이블당 여러 개 생성 가능(다양한 조회 패턴 대응)
   2) WHERE/JOIN 조건을 폭넓게 커버 가능
   3) 클러스터 인덱스처럼 데이터 전체를 재정렬하지는 않으므로, 상대적으로 변경 부담이 덜한 편
 

 ⅳ. 논 클러스터 인덱스 (Non-Clustered Index) 단점
   1) Key Lookup이 많이 발생하면 I/O가 늘고 성능이 떨어질 수 있음
   2) 인덱스가 많아질수록 저장공간과 유지보수 비용이 증가

 

 ⅳ. 논 클러스터 인덱스 (Non-Clustered Index) 사용하기 좋은 경우
   1) 자주 조회되는 조건 컬럼(특히 WHERE, JOIN에 자주 등장)
   2) 선택도가 높은 컬럼(조건을 걸었을 때 결과가 확 줄어드는 컬럼)
   3) 특정 컬럼만 빠르게 찾고 싶은 경우(예: 이메일, 사번, 사용자ID)

Ⅴ. 클러스터 인덱스(Clustered Index), 논 클러스터 인덱스(Non-Clustered Index) 비교

 클러스터 인덱스(Clustered Index) : 인덱스의 Leaf가 실제 데이터다 (데이터가 정렬되어 저장)
 논 클러스터 인덱스 ( Non- Clustered Index) : Leaf는 포인터다 (인덱스와 데이터가 분리)

정리하면, 클러스터는 “찾으면 끝”에 가깝고, 논 클러스터는 “찾고 나서 본문을 한 번 더 보러 가는 구조”가 기본입니다(물론 커버링으로 예외가 생깁니다).

Ⅵ. DBMS별로 달라지는 포인트

 ⅰ. MySQL(InnoDB)
   PK가 곧 클러스터 인덱스입니다. 논 클러스터 인덱스 Leaf에는 “RID” 대신 PK 값이 들어 있고, 그 PK로 다시 클러스터(=데이터)에서 Row를 찾습니다. 그래서 InnoDB는 PK 설계가 성능에 매우 큰 영향을 줍니다.
 ⅱ. Oracle
  기본적으로 테이블과 인덱스가 분리된 구조에 가깝습니다. IOT(Index Organized Table) 같은 구조에서만 “클러스터에 가까운” 개념이 등장합니다.
 ⅲ. SQL Server
  클러스터 인덱스를 PK와 별개로 선택할 수 있습니다(PK ≠ Clustered 가능). INCLUDE를 활용한 커버링 튜닝이 실무에서 자주 쓰입니다.