MySQL의 기본 -13

B-Tree 인덱스 vs Clustered 인덱스 (클러스터형 인덱스) 차이점 정리

B-Tree 인덱스와 클러스터형 인덱스(Clustered Index)의 차이를 명확히 이해하는 것은 MySQL 등 RDBMS의 성능 최적화에 매우 중요하다. 두 인덱스 모두 B+Tree 구조를 기반으로 하지만, 저장 방식과 역할에서 차이가 크다.

B-Tree 인덱스는 균형 잡힌 트리 구조로, 각 노드가 정렬된 키와 포인터를 가진다. 모든 리프 노드는 같은 깊이에 있어 검색 속도가 일정하다. 데이터는 물리적으로 정렬되지 않고, 보조 인덱스는 B-Tree 기반으로 동작한다. 예를 들어 기본 키(id)는 클러스터형 인덱스지만, name 같은 컬럼에 생성된 인덱스는 일반 B-Tree 보조 인덱스다.

클러스터형 인덱스는 데이터 자체가 기본 키 순서대로 물리적으로 저장되는 특수한 형태다. 기본 키가 클러스터형 인덱스 역할을 하며, 보조 인덱스는 이 기본 키 값을 참조한다. 따라서 클러스터형 인덱스의 리프 노드에는 실제 데이터가 포함되어 있어, 기본 키로 검색할 때는 바로 데이터를 반환하지만, 보조 인덱스 검색 시에는 먼저 인덱스에서 기본 키를 찾고 다시 클러스터형 인덱스에서 데이터를 조회하는 이중 조회가 발생한다.

클러스터형 인덱스는 기본 키 값 순서대로 데이터가 저장되므로, AUTO_INCREMENT를 기본 키로 사용하면 새로운 데이터가 항상 마지막 페이지에 추가되어 페이지 분할이 적고 성능 저하가 적다. 반면 UUID 같은 랜덤한 키를 사용하면 중간에 데이터가 삽입되어 페이지 분할과 트리 재조정이 빈번해져 성능 저하가 심하다.

INSERT/UPDATE가 빈번한 환경에서는 클러스터형 인덱스의 정렬 부담을 고려해야 하며, 보조 인덱스에 저장되는 기본 키 크기도 최적화 대상이다. 기본 키가 크면 보조 인덱스 크기와 I/O 비용이 증가하기 때문이다.

정리하면, MySQL(InnoDB)에서는 기본 키가 자동으로 클러스터형 인덱스가 되며, 추가 인덱스들은 일반 B-Tree 보조 인덱스로 동작한다. 클러스터형 인덱스는 기본 키 검색과 범위 검색에 뛰어난 성능을 보이지만, 보조 인덱스 활용 시에는 이중 조회 비용을 감안해야 한다. AUTO_INCREMENT 기본 키를 사용하면 페이지 분할 문제를 최소화하면서 안정적인 성능을 기대할 수 있다.