B-tree 인덱스

정렬된 키를 여러 층의 노드에 나눠 담아, 위에서 아래로 범위를 좁혀 내려가는 구조입니다.

노드를 뚱뚱하게 만드는 이유는 디스크 읽기 횟수를 줄이기 위해서입니다. 디스크 접근이 메모리보다 수천 배 느리므로, 높이를 낮추는 것이 곧 성능입니다.

100만 행에서 한 건 찾기
  풀 스캔    100만 번 비교
  B-tree     3에서 4번의 노드 읽기

흔한 실수: 이진 트리와 같은 것으로 설명하는 것. 이진 트리는 노드당 키가 하나여서 높이가 20 안팎이 되고, 그만큼 디스크를 읽어야 합니다.

해시가 이론상 빠른데도 DB 기본이 B-tree 인 이유는 실무 쿼리에 범위와 정렬이 흔하기 때문입니다.

WHERE created_at BETWEEN ? AND ?    -- 범위
ORDER BY price                      -- 정렬
WHERE name LIKE '김%'                -- 접두어

이 셋이 모두 해시로는 안 됩니다. 등가 조회만 필요한 것이 확실하고 그 차이가 병목일 때만 해시를 고려합니다.

흔한 실수: MySQL InnoDB 에서 해시 인덱스를 만들 수 있다고 답하는 것. 명시적으로는 만들 수 없고(MEMORY 엔진만 가능) 내부 적응형 해시는 엔진이 알아서 관리합니다.

WHERE DATE(created_at) = '2026-01-01'   -- 함수. 범위 조건으로 다시 쓴다
WHERE user_id = '12345'                 -- user_id 가 INT 면 변환이 일어난다
WHERE name LIKE '%김%'                   -- 앞 와일드카드

흔한 실수: 옵티마이저가 알아서 해준다고 보는 것. 함수 적용과 타입 불일치는 논리적으로 동등해도 인덱스 정렬 순서를 쓸 수 없어 옵티마이저도 방법이 없습니다.

읽기를 빠르게 하려고 쓰기와 저장 공간을 내주는 것이라, 과하면 손해가 커집니다.

그래서 쓰이지 않는 인덱스를 찾아 지우는 것이 정기 작업입니다. 대부분의 DB 가 인덱스별 사용 통계를 제공합니다.

흔한 실수: 컬럼마다 인덱스를 하나씩 만드는 것. 조건이 여러 컬럼이면 복합 인덱스 하나가 낫고, 단일 인덱스 여러 개를 합치는 방식은 대개 느립니다.