B-Tree 인덱스 원리 설명
약 90초
핵심 구조 설명 후 차이점
B-Tree 인덱스는 균형 트리 구조로, 모든 리프 노드까지의 깊이가 동일하게 유지됩니다. 검색 시 루트에서 시작해 비교 연산으로 좌·우 자식 노드를 골라 내려가기 때문에 시간복잡도는 O(log n)입니다. MySQL(InnoDB)에서는 클러스터드 인덱스라 기본키가 리프 노드에 실제 데이터 행을 직접 저장합니다. 반면 PostgreSQL은 힙 기반 저장이라 모든 인덱스가 힙의 ctid 포인터를 갖는 세컨더리 구조입니다. 범위 검색에 유리한 이유는 리프 노드들이 양방향 링크드 리스트로 연결돼 있기 때문입니다. 실무에서 LIKE '%검색어' 형태는 B-Tree를 타지 못한다는 점이 중요한 실전 포인트라고 생각합니다. 실제 쿼리 성능 튜닝 과제에서 풀 테이블 스캔이 발생하는 원인을 B-Tree 구조로 설명하면서 팀원들과 이해를 맞출 수 있었습니다. 인덱스 설계는 읽기 패턴을 먼저 분석한 뒤 결정해야 한다는 것을 배웠습니다.
이 결의 특징
균형 트리의 구조를 명확히 설명한 뒤 시간복잡도와 저장소 방식의 연관성을 순차적으로 연결합니다. 리프 노드의 양방향 링크드 리스트, LIKE '%' 검색의 제약 같은 세부 지점까지 구체적으로 언급하는 패턴입니다.
이 결이 통하는 자리
시스템 설계 초기 단계에서 인덱스 전략을 고민해야 한다는 맥락에서 신뢰를 얻습니다. 팀 내 기술 선택을 정당화할 때 원리 기반의 설명이 필요한 조직에서 특히 유용합니다.