DB 인덱스란 무엇인가요?

[Uechann]

• 인덱스의 개념
• 인덱스를 사용하는 이유
• 작동 방식
  에 대해 간단히 작성해주세요

[koreaioi]

인덱스는 책의 목차같은 개념으로, DB에 저장된 데이터를 쉽게 찾을수있도록 돕습니다.

제가 생각하는 인덱스 사용 이유는 풀스캔을 피하기 위해서라고 생각합니다.
풀스캔을 피해야하는 이유는 단순히 속도 때문이라고 생각할 수 있지만, 락의 범위를 줄이는 부가적인 효과도 가지고 있습니다.

---

추가적으로 인덱스 사용 시 어디서 빠른 속도의 이점을 얻을 수 있는 지 찾아보았습니다.

1. Range Scan 효과적
2. 커버링, 복합 인덱스
3. Order By 최적화

---

또한 인덱스는 기본 테이블 데이터 말고도 추가로 데이터가 저장되며, Btree 구조로 형성됩니다.
균형적인 트리 구조이기 때문에, 시간복잡도는 O log(n)을 가집니다.

Btree는 자식 노드를 따라 범위를 점점 좁혀가서 타겟을 찾아내고, 자식 노드끼리 양방향으로 연결되어있어서 Range Scan에도 성능이 좋습니다.

다만, 기본적으로 페이지 단위 저장이기 때문에, 꽉차게 되는 경우 트리를 재구성하게 되는 불편함이 존재합니다.
이는 쓰기작업(INSERT, UPDATE, DELETE)에서 추가 비용을 발생시킵니다. 때문에, 읽기와 쓰기 작업의 발생 비율을 고려하여 인덱스 도입을 고민해봐야한다고 생각합니다!

[softmoca]

저는 DB 인덱스를 "테이블에서 원하는 데이터를 빠르게 찾기 위해 별도로 유지하는 정렬된 자료구조"라고 이해했습니다.
책의 색인이 본문 페이지를 직접 바꾸지 않고 따로 만들어진 것처럼,
인덱스도 원본 테이블과 분리된 별도의 구조로 존재하면서 조회 속도를 끌어올립니다.

다만 인덱스는 공짜가 아니라 읽기 성능과 쓰기 성능, 저장 공간 사이의 트레이드오프를 가지는 도구이고,
"느리니까 인덱스를 걸자"가 아니라 "이 쿼리가 왜 느린지, 인덱스로 해결될 문제인지,
어떤 컬럼을 어떻게 인덱싱할지"를 먼저 따져야 한다고 생각합니다.

1. 인덱스란 무엇인가

인덱스는 테이블의 특정 컬럼에 대해 별도로 만들어둔 정렬된 자료구조입니다. 책의 뒷부분에 있는 색인(index)을 생각하면 직관적입니다.

책에서 "트랜잭션"이라는 단어가 나오는 페이지를 찾고 싶을 때, 처음부터 끝까지 한 장씩 넘기지 않습니다. 색인을 펼쳐서 "ㅌ" 항목에서 "트랜잭션 → 245p, 312p"를 확인하고 해당 페이지로 바로 갑니다.

DB도 마찬가지입니다. 인덱스가 없으면 테이블 전체를 순차적으로 읽어가며 조건에 맞는 행을 찾아야 하는데(Full Table Scan), 이는 데이터가 많을수록 비례해서 느려집니다. 인덱스가 있으면 정렬된 자료구조를 이용해 원하는 행의 위치를 빠르게 찾아갈 수 있습니다.

중요한 점: 인덱스는 원본 테이블의 일부가 아니라 별도로 존재하는 보조 자료구조입니다. 그래서 인덱스를 만들면 추가 저장 공간이 필요하고, 데이터가 변경될 때 인덱스도 함께 갱신해야 합니다.

2. 인덱스를 사용하는 이유

(a) 조회 성능 향상

가장 직접적인 이유입니다. 100만 건의 예약 데이터에서 특정 회원의 예약을 찾는다고 가정하면,

• 인덱스 없음: 100만 행을 순차 스캔 → O(N)
• 인덱스 있음: 정렬된 자료구조에서 이진 탐색에 가까운 방식으로 접근 → O(log N)

데이터 양이 늘어날수록 차이가 극적으로 커집니다.

(b) 정렬 비용 절감

ORDER BY 절에 인덱스가 걸린 컬럼이 있다면, DB는 별도 정렬 작업 없이 이미 정렬된 인덱스를 그대로 활용할 수 있습니다. 정렬은 데이터가 많을 때 매우 비싼 작업이라, 인덱스로 이를 회피할 수 있다는 점도 중요한 이점입니다.

(c) 유일성 보장 (Unique Index)

UNIQUE 제약 조건은 내부적으로 유니크 인덱스로 구현됩니다. 이번 미션에서 "같은 날짜, 같은 시간, 같은 테마에 예약이 하나만 가능하다"는 규칙을 UNIQUE(date, time_id, theme_id)로 강제할 수 있는데, 이게 동시성 상황에서도 중복을 막아주는 이유는 인덱스가 유일성 검사를 수행하기 때문입니다.

(d) 조인 성능 향상

조인 조건의 컬럼에 인덱스가 있으면 조인 알고리즘(특히 Nested Loop Join)이 훨씬 효율적으로 동작합니다. 외래키 컬럼에 인덱스가 자주 걸리는 이유가 여기에 있습니다.

3. 인덱스는 어떻게 동작하는가

B-Tree 인덱스가 기본

대부분의 RDBMS는 인덱스로 B-Tree(정확히는 B+Tree) 를 사용합니다. 왜 단순한 이진 탐색 트리나 해시가 아닌 B-Tree냐 하면, 디스크 I/O 특성에 최적화되어 있기 때문입니다.

B-Tree의 핵심 특징:

• 한 노드에 여러 키가 들어감 → 트리의 높이가 낮음 → 디스크 접근 횟수가 적음
• 항상 정렬된 상태를 유지 → 범위 검색(BETWEEN, >, <)에 강함
• 자가 균형 → 삽입/삭제 후에도 검색 성능이 일정함

예를 들어 100만 건 데이터의 B-Tree 인덱스 높이는 보통 3 정도입니다.
즉 100만 건에서 원하는 값을 찾는 데 디스크 접근이 3번이면 됩니다.

조회 흐름

SELECT * FROM reservation WHERE member_id = 5라는 쿼리가 있다고 가정하면,

1. member_id 컬럼에 인덱스가 있는지 확인 (옵티마이저가 판단)
2. 인덱스 B-Tree를 따라 내려가며 member_id = 5인 엔트리를 찾음
3. 인덱스 엔트리에는 실제 테이블 행의 위치(주소)가 함께 저장되어 있음
4. 그 위치로 가서 실제 행을 읽어옴

이 마지막 단계를 "테이블 lookup" 이라고 부르는데, 이게 한 번 더 발생하기 때문에 인덱스가 항상 빠른 건 아닙니다. 조회할 행이 너무 많으면(예: 전체의 30% 이상) 차라리 Full Table Scan이 더 빠른 경우도 있습니다. 옵티마이저는 이런 비용을 계산해서 인덱스 사용 여부를 결정합니다.

쓰기 시 동작

INSERT, UPDATE, DELETE가 발생하면 원본 테이블뿐 아니라 관련된 모든 인덱스도 함께 갱신됩니다. 이는 인덱스의 가장 큰 비용이기도 합니다.

• 인덱스가 5개인 테이블에 INSERT → 테이블 1번 + 인덱스 5번 = 총 6번의 쓰기

그래서 인덱스를 많이 만들수록 조회는 빨라지지만 쓰기는 느려지는 트레이드오프가 생깁니다.

4. 인덱스의 트레이드오프

저는 인덱스를 다룰 때 가장 중요한 게 "인덱스는 공짜가 아니다" 라는 인식이라고 생각합니다.

비용 1. 추가 저장 공간

인덱스는 별도 자료구조이므로 디스크 공간을 차지합니다. 인덱스가 많은 테이블은 데이터 자체보다 인덱스가 더 큰 경우도 있습니다.

비용 2. 쓰기 성능 저하

위에서 언급한 것처럼 INSERT/UPDATE/DELETE 시 모든 관련 인덱스가 갱신되어야 합니다. 특히 자주 변경되는 컬럼에 인덱스를 걸면 쓰기 성능이 눈에 띄게 떨어질 수 있습니다.

비용 3. 옵티마이저 판단 비용

인덱스가 많아질수록 옵티마이저가 어떤 인덱스를 쓸지 판단하는 비용도 늘어납니다. 드문 경우지만 인덱스가 너무 많으면 옵티마이저가 잘못된 인덱스를 선택할 수도 있습니다.

그래서 판단 기준은

• 자주 조회되는 컬럼 → 인덱스 후보
• 자주 변경되는 컬럼 → 인덱스 신중
• 카디널리티가 낮은 컬럼(예: 성별, 상태값처럼 종류가 적은 컬럼) → 인덱스 효과가 작음
• WHERE, JOIN, ORDER BY에 자주 등장하는 컬럼 → 인덱스 효과가 큼

5. 인덱스가 동작하지 않는 경우

인덱스를 걸어도 실제로 사용되지 않는 경우가 자주 있습니다. 저는 이걸 모르고 인덱스만 추가하면 성능 문제가 해결될 거라 기대하는 게 가장 흔한 함정이라고 생각합니다.

(a) 컬럼에 함수/연산이 적용된 경우

-- 인덱스가 동작하지 않음
SELECT * FROM reservation WHERE YEAR(date) = 2026;

-- 인덱스가 동작함
SELECT * FROM reservation WHERE date BETWEEN '2026-01-01' AND '2026-12-31';

(b) LIKE의 와일드카드가 앞에 있는 경우

-- 인덱스가 동작하지 않음
SELECT * FROM member WHERE name LIKE '%kim';

-- 인덱스가 동작함
SELECT * FROM member WHERE name LIKE 'kim%';

(c) 복합 인덱스의 순서 문제

INDEX(date, time_id, theme_id)라는 복합 인덱스가 있을 때,

-- 인덱스가 잘 동작함 (앞에서부터 매칭)
WHERE date = '2026-05-27' AND time_id = 1

-- 인덱스가 부분적으로만 동작하거나 못 함 (date 없이 사용)
WHERE time_id = 1 AND theme_id = 3

복합 인덱스는 "왼쪽부터 순서대로" 사용될 때만 효과적입니다. 이 원칙을 leftmost prefix rule이라고 부릅니다.

(d) 타입이 맞지 않는 비교

-- member_id가 BIGINT인데 문자열로 비교 → 인덱스가 동작하지 않을 수 있음
WHERE member_id = '5'

이런 함정들이 있어서, 인덱스를 추가한 뒤에는 반드시 EXPLAIN으로 옵티마이저가 실제로 인덱스를 사용하는지 확인해야 한다고 생각합니다.

6. 미션과 연결지어 보면

이번 예약 미션에서 인덱스를 고민할 만한 지점이 몇 군데 있습니다.

(a) 중복 예약 방지를 위한 UNIQUE INDEX

CREATE UNIQUE INDEX idx_reservation_unique 
ON reservation(date, time_id, theme_id) 
WHERE status = 'RESERVED';

"같은 날짜, 같은 시간, 같은 테마에 예약은 하나만"이라는 규칙을 DB 레벨에서 강제하는 가장 안전한 방법입니다. 이전 격리 수준 토론에서도 정리했듯, 애플리케이션 코드의 검증만으로는 동시성 상황에서 정합성이 깨질 수 있어 DB의 유니크 제약이 최종 방어선이 됩니다.

다만 논리 삭제(status = 'CANCELLED')를 채택했다면, 취소된 예약은 유니크 제약에서 제외되어야 하므로 부분 인덱스(MySQL은 미지원, PostgreSQL은 지원)나 다른 방식을 고민해야 합니다.

(b) 조회 패턴에 따른 인덱스

• "특정 회원의 예약 목록" → member_id 인덱스
• "특정 날짜의 예약 조회" → date 인덱스
• "특정 날짜 + 테마의 예약" → (date, theme_id) 복합 인덱스

어떤 API가 자주 호출되는지에 따라 인덱스 전략이 달라집니다.

(c) 외래키 컬럼

time_id, theme_id, member_id 같은 외래키는 조인에 자주 사용되므로 인덱스가 자주 걸립니다. MySQL은 외래키 제약을 만들면 자동으로 인덱스를 생성하기도 합니다.

저의 접근 순서

저는 인덱스를 미리부터 빽빽하게 거는 것보다, "실제로 어떤 쿼리가 느린지 측정 → EXPLAIN으로 실행 계획 확인 → 필요한 인덱스만 추가" 순서가 더 건강하다고 생각합니다. 미션 초반부터 가능한 인덱스를 다 거는 건 오히려 학습에도 좋지 않다고 봅니다. 느린 쿼리를 만나고, 왜 느린지 분석하고, 인덱스로 해결되는 경험이 인덱스의 본질을 가장 잘 가르쳐준다고 생각합니다.

7. 정리

저는 인덱스를 이렇게 정리할 수 있을 것 같습니다.

"인덱스는 조회 성능을 위해 쓰기 성능과 저장 공간을 내주는 거래이고, 책의 색인처럼 원하는 데이터로 빠르게 도달하기 위한 별도의 정렬된 자료구조이다."

핵심 요점:

• 인덱스는 별도 자료구조(주로 B-Tree)로, 정렬된 상태를 유지하며 빠른 검색을 가능하게 한다
• 조회는 빨라지지만 쓰기는 느려지고, 저장 공간도 추가로 든다 — 공짜가 아니다
• 컬럼에 함수 적용, LIKE 와일드카드 앞 위치, 복합 인덱스 순서 위반 등으로 인덱스가 무효화될 수 있다
• 유니크 인덱스는 단순한 성능 도구가 아니라 동시성 상황에서 정합성을 지키는 최종 방어선이다
• 인덱스는 "걸어두면 좋은 것"이 아니라 "필요한 쿼리에 맞게 설계하는 것"이다

결론적으로 인덱스를 잘 다루는 능력은 "어떤 컬럼에 인덱스를 걸까" 보다 "이 쿼리가 왜 느린지 진단하고, 인덱스가 해결책인지 판단하고, EXPLAIN으로 검증하는 능력" 에 가깝다고 생각합니다.