🔍 DB 인덱스 - 빠른 검색의 비밀

 

데이터베이스에 수십만, 수백만 건의 데이터가 쌓이면 검색 속도가 눈에 띄게 느려짐.

SELECT * FROM user WHERE name = '영식';

 

이 쿼리가 1초 이상 걸린다면, 문제는 단순히 CPU나 네트워크가 아님.

대부분은 인덱스가 없거나 잘못 설정된 경우임.

 

1️⃣ 인덱스란?

데이터베이스에서 인덱스는

데이터를 빠르게 찾기 위한 별도의 자료 구조.

 

📖 책의 모든 페이지를 앞에서부터 한 장씩 넘기며 찾는 게 Full Scan

📚 목차를 보고 바로 해당 페이지로 가는 게 Index Scan

 

즉, 인덱스는 검색 성능을 높이기 위한 추가 데이터 구조(B-Tree, Hash 등)로,

WHERE, JOIN, ORDER BY 등에 사용됨.

 

2️⃣ 인덱스가 없으면 어떤 일이 생길까?

테이블에 인덱스가 없으면,

DB는 전체 테이블을 처음부터 끝까지 읽는 Full Table Scan을 수행함.

SELECT * FROM users WHERE email = 'test@duck.com';

 

데이터가 10건일 땐 괜찮지만,

100만 건이 되면 쿼리 하나에도 수천 ms가 걸림.

 

인덱스를 추가하면,

DB는 인덱스 트리를 탐색해 해당 레코드의 위치를 빠르게 찾음.

 

3️⃣ 인덱스의 내부 구조

DB 인덱스는 보통 B-Tree 자료구조로 관리됨.

             [email]
             /      \
       test@...   user@...
       /               \
  (row pointer)     (row pointer)

• Root Node: 가장 상위 노드, 검색 시작점
• Branch Node: 경로를 안내하는 중간 노드
• Leaf Node: 실제 데이터 위치(ROWID) 저장

인덱스는 정렬된 상태를 유지하므로,

검색(=, <, >, BETWEEN)과 정렬(ORDER BY) 모두 빠르게 처리 가능.

 

4️⃣ 인덱스는 항상 좋은 걸까?

그렇지 않다!

인덱스는 읽기 성능을 높이지만, 쓰기 성능을 낮춤.

 

즉, 읽기 중심 시스템에는 유리하지만,

쓰기 중심 시스템에서는 오히려 부하가 생길 수 있음.

 

5️⃣ 인덱스를 효과적으로 사용하는 패턴

패턴	예시	설명
단일 컬럼 인덱스	CREATE INDEX idx_user_email ON user(email)	특정 필드 검색 속도 향상
복합 인덱스	CREATE INDEX idx_user_name_age ON user(name, age)	두 필드 조합 검색 최적화
커버링 인덱스	쿼리에서 필요한 모든 컬럼이 인덱스에 포함된 경우	테이블 접근 없이 인덱스로만 처리
클러스터형 인덱스	MySQL InnoDB의 PRIMARY KEY	실제 데이터가 정렬된 상태로 저장

 

✅ 복합 인덱스 주의:

복합 인덱스는 왼쪽부터 순서대로 검색할 때만 효과적.

# 인덱스: (name, age)
WHERE name = '영식' ✅ (사용됨)
WHERE age = 27 ❌ (사용 안됨)

 

6️⃣ 인덱스가 사용 중인지 확인하는 방법

MySQL 기준으로 EXPLAIN 명령어로 쿼리 실행 계획을 확인 할 수 있음.

EXPLAIN SELECT * FROM user WHERE email = 'test@duck.com';

 

출력에서 type=ref 또는 range가 나오면 인덱스 사용 중.

반면 type=ALL 은 Full Table Scan, 즉 인덱스가 사용되지 않은 상태.

 

7️⃣ 실무에서 자주 하는 실수와 팁

❌ 너무 많은 인덱스 생성

→ 쿼리마다 인덱스를 추가하면 쓰기 부하와 스토리지 낭비 발생

✅ 자주 조회되는 컬럼 + 선택도가 높은 컬럼만 인덱스 생성

 

❌ 와일드카드 검색 남용

WHERE name LIKE '%영%';  -- 인덱스 사용 안 됨

✅ 접두사 검색(LIKE '영%') 형태로 설계하거나 검색엔진(Elasticsearch)과 병행

 

❌ 형 변환으로 인덱스 무효화

WHERE DATE(created_at) = '2025-10-27';  -- ❌
WHERE created_at >= '2025-10-27 00:00:00' 
  AND created_at < '2025-10-28 00:00:00';  -- ✅