인덱스 자료구조 비교

선택 원리

B+Tree는 기본값이고, 패턴이 뚜렷할 때만 특화 인덱스로 갈아탑니다.

범위/정렬 → B+Tree

정확한 = 검색 → Hash

값 종류가 적음 → Bitmap

핵심은 이름을 외우는 것이 아니라, 어떤 질의와 데이터 모양이 인덱스 선택을 바꾸는지 보는 것입니다. 범용성은 B+Tree가 가져가고, 나머지는 특정 조건에서만 더 강합니다.

질의/데이터 패턴

유리한 인덱스

왜 여기서 강한가

범위 검색, 정렬, 대부분의 일반 조건

기본 선택지로 가장 먼저 고려

B+Tree 기본값

정렬된 키 순서를 유지해 범위 탐색과 순차 접근이 자연스럽습니다. 그래서 대부분의 일반 인덱스가 여기서 시작됩니다.

정확히 같은 값 하나를 바로 찾고 싶을 때

key = 100 같은 동등 조건

Hash Index 특화

해시 버킷으로 바로 가므로 동등 검색은 빠르지만, 범위 검색은 어렵습니다. MySQL Memory 엔진에서 쓰이며, InnoDB는 Adaptive Hash Index를 둡니다.

값 종류가 적은 컬럼을 여러 개 함께 거를 때

성별, 상태 같은 낮은 카디널리티

Bitmap Index 특화

값마다 비트맵을 두고 AND/OR 연산으로 필터를 빠르게 합칩니다. OLAP 계열에서 유리하며 Oracle에서 자주 언급되는 방식입니다.

위치, 영역, 겹침처럼 공간 관계를 볼 때

지도, 좌표, 사각형 범위

R-Tree 특화

공간 객체의 범위를 묶어 탐색하므로 지도/GIS 질의에 맞습니다. 위치 기반 검색은 B+Tree보다 이런 구조가 더 자연스럽습니다.

전문 검색, 배열, 포함 관계를 다룰 때

PostgreSQL 텍스트, 배열 컬럼

GIN / GiST 특화

토큰 집합이나 복합 구조를 색인해 포함 여부와 유사 관계를 찾기 좋습니다. 관계형 기본 범위를 넘어서는 자료형에서 특히 빛납니다.

쓰기량이 많고 계속 적재되는 데이터

로그, 시계열, 쓰기 최적화

LSM-Tree 특화

메모리에 먼저 쓰고 나중에 병합해 디스크 쓰기 비용을 줄입니다. 읽기보다 지속적인 적재가 더 중요한 저장 엔진에서 자주 선택됩니다.

기억할 점

Hash는 가장 빠른 경우가 분명하지만 적용 범위가 좁고, Bitmap은 값 종류가 적은 컬럼을 조합할 때 강합니다. 그래서 둘 다 “모든 인덱스를 대체”하는 구조가 아니라, B+Tree가 놓치는 특정 패턴을 메우는 특화 선택지로 이해하면 됩니다.