DB 인덱스(Index)란?

✅들어가면서

데이터베이스를 사용하다 보면 이런 상황을 자주 겪다.

“데이터가 많아지니까 조회 속도가 너무 느린데?”

이 문제를 해결하는 핵심 기술이 바로 인덱스(Index) 이다.

---

⭐ 인덱스(Index)란?

인덱스는 한마디로 데이터를 빠르게 찾기 위한 “검색용 구조”이다.

 

전화번호부를 예로들어서 이해해보자.

• 이름 순으로 정렬되어 있음
• 원하는 사람을 빠르게 찾을 수 있음

만약 정렬이 없다면?

👉 처음부터 끝까지 다 찾아야 함 (Full Scan)

 

매우 번거롭고 귀찮은 작업일 것이다.

 

데이터베이스에서도 똑같다.

• 인덱스 없음 → 전체 탐색
• 인덱스 있음 → 빠르게 위치 찾기

---

 📌 인덱스가 왜 빠를까?

인덱스는 단순히 데이터가 아니라 “값 + 데이터 위치”를 함께 저장한다.

 

그래서

1. 조건에 맞는 값을 빠르게 찾고
2. 해당 데이터 위치로 바로 이동

전체를 뒤질 필요가 없는 것이다.

💡예시: 회원 검색

회원 테이블에 100만 명 데이터가 있다고 가정해보자.

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

 

 이때 나는 이메일이 'abc@test.com'인 유저를 찾고 싶다.

 

❌ 인덱스 없을 때

• 100만 건 전부 비교 (Full Scan)

✅ 인덱스 있을 때

• email 인덱스를 통해 바로 위치 찾음
• 몇 번의 탐색으로 끝

---

 🤔 인덱스가 항상 좋을까?

결론부터 말하자면 인덱스는 무조건 좋은 게 아니다.

❌ 인덱스의 단점

1. 저장 공간 추가 사용

• 인덱스도 별도의 데이터 구조
• 테이블 크기의 약 10~20% 추가 사용

2. 쓰기 성능 저하

데이터 변경 시:

• INSERT → 인덱스 추가
• UPDATE → 인덱스 재정렬
• DELETE → 인덱스 제거

👉 작업이 더 많아짐

❌ 인덱스가 비효율적인 경우

• INSERT / UPDATE / DELETE가 매우 빈번한 컬럼
• 데이터 중복도가 높은 컬럼
• 조회 거의 안 하는 컬럼

즉, 인덱스는 "필요한 경우에만" 써야 한다!

---

🤔 그렇다면 인덱스가 필요한 경우가 뭔데?

1. 조회가 많은 컬럼
   • WHERE 조건 자주 사용
2. 정렬이 자주 발생
   • ORDER BY
3. 조인에 사용되는 컬럼
   • JOIN 조건
4. 데이터 중복이 적은 컬럼
   • email(좋음)
   • 성별(나쁨)

---

⭐ 인덱스 내부 구조

인덱스는 내부적으로 자료구조를 사용한다.

대표적으로 2가지가 있다.

1️⃣ Hash Index

해시 인덱스는 (Key, Value)로 데이터를 저장하는 자료구조 중 하나로 빠른 데이터 검색이 필요할 때 유용하다.

해시 인덱스는 Key값을 이용해 고유한 index를 생성하여 그 index에 저장된 값을 꺼내오는 구조이다.

 

✅ 특징

• 검색 속도 매우 빠름 (O(1))
• 대신 범위 검색 불가능(<, >)

2️⃣ B+Tree Index

B+Tree 인덱스는 DB의 인덱스를 위해 자식 노드가 2개 이상인 B-Tree를 개선시킨 자료구조이다. 대부분의 DB(MySQL, Oracle 등)에서 사용된다.

 

✅ 특징

• 정렬된 구조
• 범위 검색 가능
• 트리 구조

💡예시

WHERE price BETWEEN 1000 AND 5000

👉 B+Tree는 가능
👉 Hash는 불가능

 

🔄 B+Tree 구조 핵심

 

• 실제 데이터는 리프 노드에 저장
• 리프 노드끼리 연결됨
• 빠른 순차 탐색 가능