"인덱스를 걸었는데 왜 여전히 느리죠?" 슬로우 쿼리를 만나면 흔히 듣는 질문입니다. 원인은 대개 인덱스 종류를 잘못 골랐기 때문입니다. 인덱스는 책 뒤의 색인과 같지만, 색인을 정렬해 두느냐 해시로 흩뿌리느냐에 따라 잘하는 일이 완전히 달라집니다. 종류별 특성을 알면 "왜 안 타는지"가 보입니다.
인덱스 종류 한눈에
| 종류 | 자료구조 | 강한 쿼리 | 약한 쿼리 |
|---|---|---|---|
| B-tree | 균형 트리(정렬 유지) | 범위·정렬·등치 | 부분 문자열 검색 |
| Hash | 해시 테이블 | 정확히 일치(=) | 범위·정렬 |
| 풀텍스트 | 역색인 | 단어·문장 검색 | 정확한 등치 비교 |
| GIN/GiST | 역색인·공간 | 배열·JSON·위치 | 단순 스칼라 |
핵심은 B-tree가 정렬을 유지해 범위에 강하고, Hash는 정렬을 버린 대신 단일 등치에 빠르며, 풀텍스트는 본문을 단어로 쪼개 검색한다는 점입니다.
B-tree — 기본이자 만능
대부분의 인덱스는 B-tree입니다. 값을 정렬해 트리로 보관하므로 범위 조건과 정렬에 모두 강합니다.
CREATE INDEX idx_orders_created ON orders (created_at);
SELECT * FROM orders WHERE created_at >= '2028-01-01' ORDER BY created_at;
>= 같은 범위와 ORDER BY를 한 인덱스로 처리합니다. 다만 LIKE '%검색어%'처럼 앞에 %가 붙으면 정렬 순서를 못 써서 인덱스를 타지 못합니다. 이게 "인덱스 걸었는데 느린" 흔한 함정입니다.
Hash — 등치 비교 전용
Hash 인덱스는 값을 해시로 바꿔 저장합니다. = 비교는 매우 빠르지만 정렬 정보가 없어 범위 검색에는 쓸 수 없습니다.
SELECT * FROM sessions WHERE token = 'abc123';
세션 토큰처럼 "정확히 이 값"만 찾을 때 적합합니다. 다만 PostgreSQL 등에서는 B-tree가 등치도 충분히 빨라, Hash를 따로 쓰는 경우는 드뭅니다.
풀텍스트 — 본문 검색
게시글 본문에서 단어를 찾으려고 LIKE '%단어%'를 쓰면 인덱스를 못 타 전체를 훑습니다. 풀텍스트 인덱스는 본문을 단어 단위로 쪼갠 역색인을 만들어 이를 해결합니다.
SELECT * FROM posts WHERE MATCH(body) AGAINST('데이터베이스 인덱스');
검색 엔진처럼 단어·문장 검색에 강하지만, 정확한 등치 비교에는 B-tree가 낫습니다.
요점 정리
- B-tree는 정렬을 유지해 범위·정렬·등치에 두루 강한 기본 선택지.
- Hash는
=단일 비교에만 빠르고 범위·정렬엔 못 쓴다. - 본문 단어 검색은
LIKE대신 풀텍스트(역색인)를 쓴다.
EXPLAIN으로 쿼리가 어떤 인덱스를 타는지 직접 보고, 인덱스 유무에 따라 속도가 어떻게 달라지는지 확인하는 실습은 데이터베이스 트랙에서 회원가입 없이 무료로 할 수 있습니다.