인덱스(Index)란?

이건우·2025년 4월 3일

웹 프로그래밍

목록 보기
42/43

DB를 쓰면서 테스트를 하다 보면, 이런 순간이 꼭 옵니다.

"왜 이렇게 SELECT가 느리지...?"

쿼리문이 잘못됐나?, DB가 느린 건가?, 서버가 문제인가?, 버그인가?
대부분의 경우, 인덱스를 설정 안했다는 것을 깨닫게 됩니다.

저도 인덱스를 추상적으로 빨라지는 매직워드 정도로만 알고 넘어갔는데,
잘못 설계하면 성능이 수십배 차이가 나기도 하는 인덱스,
제대로 짚고 넘어가 보겠습니다.

인덱스란?

DB에서 데이터를 빠르게 찾기 위한 자료구조입니다.

특정 데이터를 무엇을 기준으로 어떻게 찾아낼 것인가?

를 지정하는 것입니다.

쉽게 말하면, 도서관에서 책을 찾는 것과 같습니다.

인덱스가 없으면 -> 책 전체를 다 뒤져야 함
인덱스가 있으면 -> 목차로 바로 페이지 찾음

테이블 전체를 다 읽는 것보다,
미리 정리된 색인표에서 이메일 위치를 찾아 바로 이동하는 것이 훨씬 빠르겠죠.

그럼 이렇게 중요한 인덱스,

언제 사용하는가?

인덱스는 조회 성능이 중요한 상황이라면 적극적으로 고려해야 합니다.
(거의 대부분의 상황이긴 합니다...)

  • WHERE 조건으로 특정 행을 찾는 경우

  • ORDER BY 정렬이 필요한 경우

  • JOIN으로 테이블을 연결하는 경우

  • 페이지네이션 (OFFSET LIMIT) 쿼리 등

대부분의 경우 데이터가 최소 1만행 보통 10만행쯤은 될 것이니,
인덱스를 사용하긴 해야하는데....

어떤 인덱스가 있는가?

📘 기본 인덱스 (Primary Index)

자주 조회되는 단일 컬럼에 적용되며,
키와 해당 키가 가리키는 데이터 레코드 간의 매핑을 관리합니다.
일반적으로 B-tree(밸런스 트리) 구조를 사용하며,
키 값들이 정렬된 상태로 저장되고,
각 키는 실제 데이터의 위치를 가리키는 포인터를 포함하여 색인을 도와줍니다.

📘 유니크 인덱스 (Unique Index)

중복을 허용하지 않는 컬럼(또는 컬럼 조합)에 대해 생성됩니다.
이 인덱스는 키 값이 고유하다는 것을 보장하며,
주로 B-tree 또는 해시 테이블을 기반으로 구현됩니다.
이메일, 주민등록번호처럼 식별 목적의 컬럼에 자주 사용됩니다.

📘 복합 인덱스 (Composite Index)

두 개 이상의 컬럼을 결합하여 하나의 인덱스로 구성한 방식입니다.
주로 B-tree 구조를 사용하며,
컬럼 조합 전체를 하나의 키처럼 다뤄 다중 조건 검색에 최적화되어 있습니다.

❗️ 주의 ❗️
컬럼 순서가 중요합니다.
왼쪽 컬럼부터 순서대로 사용해야 인덱스를 제대로 활용할 수 있습니다.

📘 풀텍스트 인덱스 (Full-Text Index)

텍스트 데이터를 대상으로, 단어 단위로 색인을 생성합니다.
인버티드 인덱스(역색인) 구조를 사용하여,
각 단어가 어떤 문서에 등장하는지를 추적합니다.

MATCH(title) AGAINST('Spring')와 같은 검색 엔진 스타일의 쿼리에 유용합니다.

📘 해시 인덱스 (Hash Index)

각 키에 대해 해시 함수를 적용한 값을 인덱스로 사용하는 방식입니다.
해시 테이블 구조를 활용하여, 키를 데이터 저장 위치와 직접 연결합니다.

❗️ 주의 ❗️
비교에는 빠르지만,
범위 검색(>, <, BETWEEN 등)에는 적합하지 않습니다.
주로 MEMORY 엔진에서 사용됩니다.

이렇게 보니까 무작정 사용하면 안될 것 같은데...

인덱스의 장단점

✅ 장점

  • 조회 속도 대폭 향상 (특히 대용량 테이블일수록 효과 ↑)

  • 정렬, 그룹핑, 조인 등에도 성능 이득

  • 쿼리 튜닝할 때 거의 필수 도구

❌ 단점

  • INSERT, UPDATE, DELETE 시 비용 발생
    → 데이터뿐만 아니라 인덱스도 같이 갱신

  • 디스크 공간 추가 사용

  • 인덱스를 너무 많이 만들면 오히려 느려질 수 있음

총 인덱스 5~6개 걸려 있는 쿼리에서
쿼리 옵티마이저가 인덱스를 못 고르고 풀스캔 해버릴 수도 있습니다.....

정리

인덱스는 개발자 입장에서 거의 필수인 도구입니다.
하지만 “무조건 빠르다”는 아닙니다.

인덱스는 필요한 곳에만, 정확하게 써야 진짜 성능이 나옵니다.

조회는 빨라지지만, 쓰기는 느려진다는 걸 항상 기억하면서
읽기 많은 테이블 중심으로, 최소한의 인덱스로 설계하는 게 핵심입니다!

profile
새싹개발자

0개의 댓글