같은 값 찾기와 기간 조회가 모두 필요한 컬럼에 B+tree와 해시 인덱스 중 무엇을 선택하나요?

기간 조회까지 필요한 컬럼이라면 기본 선택은 정렬 순서를 보존하는 B+tree입니다. id = 10 같은 동등 검색뿐 아니라 created_at >= 시작 AND created_at < 끝, 접두 검색, 정렬된 결과의 일부에도 인덱스의 시작점을 찾은 뒤 연속된 리프를 스캔하는 방식으로 대응할 수 있습니다. 해시 인덱스는 키의 해시값으로 버킷을 찾으므로 동등 비교에는 잘 맞지만 키의 대소 관계를 보존하지 않습니다. 따라서 범위와 ORDER BY가 한 요구에 포함되면 해시를 기본 해법으로 택하지 않겠습니다.

구조의 장점보다 실제 접근 경로를 봅니다

B+tree는 내부 노드에서 여러 키를 묶어 높이를 낮추고, 리프에서 인접한 키를 순서대로 읽는 구조가 일반적입니다. 범위가 좁으면 시작 위치를 한 번 찾은 후 필요한 행만 읽을 수 있습니다. 다만 인덱스가 있다고 전체 비용이 작아지는 것은 아닙니다. 범위가 넓거나 조건 선택도가 낮으면 인덱스에서 많은 행을 찾고 다시 테이블로 lookup하는 비용이 스캔보다 커질 수 있습니다. 정렬 제거가 가능한지, 반환 컬럼을 인덱스가 모두 포함하는지도 함께 보겠습니다.

해시는 해시 충돌이 생기면 실제 키를 다시 비교해야 하며, 버킷 재구성이나 메모리 구조의 비용도 있습니다. 해시값만으로 10보다 큰 키를 모을 수 없으므로 범위 검색을 위해 전체 버킷을 훑어야 할 수 있습니다. ‘평균 O(1)’은 특정 자료구조의 이상적 탐색 단계에 대한 설명이지 네트워크, 행 접근, 반환 바이트, 동시 잠금까지 포함한 질의 시간의 보장은 아닙니다.

DB 엔진의 계약을 분리합니다

B+tree라는 이름은 많은 관계형 DBMS에서 일반적인 기본 인덱스 선택이지만, 실제로는 PostgreSQL의 인덱스 종류, MySQL/InnoDB의 클러스터링, SQL Server의 힙·클러스터드 구조가 비용 모델을 다르게 만듭니다. 해시 인덱스의 지원 연산과 저장 엔진별 제약도 다릅니다. 어떤 엔진에서는 해시가 메모리 테이블이나 특정 연산에만 의미가 있고, 어떤 엔진에서는 동등 조건 외의 최적화가 제한됩니다. 그러므로 제품 이름만 보고 ‘해시가 더 빠르다’고 말하지 않고 현재 버전의 지원 범위와 EXPLAIN 또는 실제 실행 계획을 확인하겠습니다.

쓰기 때 인덱스 노드를 갱신하고 저장 공간과 버퍼를 사용하므로 인덱스를 두 종류 모두 추가해 읽기만 비교하지 않겠습니다. 대표적인 작은 범위·큰 범위·동등 조회와 실제 데이터 편중에서 논리 읽기, 실제 반환 행, p95·p99 지연, 삽입·삭제 지연을 측정하겠습니다. 결론은 범위나 순서가 있으면 B+tree를 우선 검토하고, 범위·정렬이 전혀 없고 해당 엔진의 해시 구현이 검증된 좁은 동등 조회에서만 해시를 채택하는 것입니다.

또한 인덱스의 논리 구조와 실제 데이터 접근을 분리해 보겠습니다. 리프에서 키를 찾았더라도 반환 컬럼을 위해 랜덤 페이지를 많이 읽으면 캐시가 차고 지연 꼬리가 길어질 수 있습니다. 범위가 아주 넓으면 순차 스캔이나 병렬 스캔이 더 나을 수 있고, 해시도 버킷 충돌과 노드 메모리 접근이 비용이 됩니다. 작은 벤치마크의 평균값보다 실제 파라미터 분포와 p99, 쓰기 시 인덱스 유지량을 기준으로 결론을 내리겠습니다.