DB에서 인덱스 생성 시 고려 사항

DB에서 인덱스를 생성한 뒤에도 데이터가 계속 들어오면 인덱스가 증가(커지는) 이유는 단순합니다.
인덱스는 “데이터 페이지”가 아닌 별도의 B-Tree 구조로 저장되며, 새로운 키 값이 들어올 때마다 그 B-Tree에 새 노드(또는 분할)가 추가되기 때문입니다. 요약하면 다음과 같습니다.

1.  
   • 테이블은 힙(Heap) 또는 클러스터드 인덱스로 저장되고,
   • 인덱스는 독립적인 B-Tree로 저장됩니다.
2. 인덱스 ≠ 테이블
3. B-Tree는 정렬 유지 구조
   • 새 키를 삽입하면 정렬 순서에 맞는 위치를 찾아야 하므로 리프·브랜치 노드에 공간이 필요합니다.
   • 리프 페이지가 가득 차면 페이지 분할(split) 이 발생하고, 상위 브랜치 노드에 새 키가 하나 더 기록됩니다.
4. 삭제·업데이트도 증가 요인
   • 삭제 마크(ghost record)만 남기면 실제 공간은 회수되지 않습니다.
   • 업데이트는 “삭제 + 삽입”으로 처리되므로 인덱스 키가 변경되면 두 배로 기록됩니다.
5. 결론
   “인덱스는 데이터가 증가할수록 그만큼의 키를 저장할 공간이 필요하고, B-Tree 구조 특성상 페이지 분할이 반복되어 용량이 계속 커집니다.”

따라서 인덱스를 생성했다고 해서 용량이 고정되지 않으며, 데이터 증가율과 인덱스 컬럼의 카디널리티에 비례해 지속적으로 증가합니다.

 

 

아래는 “책장→서랍→나누기”를 한눈에 보여 주는 텍스트 그림입니다.
(종이에 쉽게 그려 볼 수 있도록 터미널 문자만 사용했어요)

Copy

1권만 있을 때
┌-----------┐
│  [공룡사전] │
└-----------┘
한 서랍, 한 권 → 정렬 끝!

Copy

3권이 되었지만 아직 4권 미만 → 그냥 옆에 꽂는다
┌---------------------------┐
│ [공룡사전] [바나나] [캔디] │
└---------------------------┘
왼쪽 → 가운데 → 오른쪽 순서 완성!

Copy

5권이 되면 ‘서랍 꽉 참!’ → 가운데 책 하나를 골라 위층으로 올리고 둘로 쪼갬 (분할)
        위층(새 서랍)
      ┌-------------┐
      │   [바나나]   │ ← 가운데 책이 상위 키가 됨
      └-------------┘
         ↙        ↘
┌-----------┐   ┌-----------┐
│[공룡사전] │   │[캔디][다이어트]│
└-----------┘   └-----------┘
(왼쪽 서랍)     (오른쪽 서랍)

이제 찾을 때:
“나는 캔디가 필요해!”
1. 위층 [바나나] 보다 캔디가 뒤 → 오른쪽 서랍으로!
2. 오른쪽 서랍에 가면 [캔디]가 바로 있다.
총 2번만 점프!

Copy

계속 책이 들어오면 위층도 꽉 차고, 그 위층도 생김 (2층, 3층…)
但最终 찾는 단계는 항상 3~4번 안쪽 (B-Tree의 높이가 거의 변하지 않음)

그리는 팁

1. 서랍은 박스 모양 ┌─┐로 그린다.
2. 위층으로 올라가는 화살표는 ↙↘로 표시.
3. 분할될 때 가운데 글자를 빨간색 펜으로 칠하면 “나누는 기준”이 눈에 확 들어온다.

이 그림을 보면
“책이 늘어날수록 서랍(페이지)이 늘어나지만, 항상 정렬되어 있고, 위층만 보고 왼쪽/오른쪽을 골라 들어가면 금방 찾을 수 있다”는 B-Tree의 핵심이 이해할 수 있어요!