티스토리 뷰
목차
이번 포스팅에서는 "인덱스"의 개념을 기초부터 시작해, 실무에서 왜 중요한지, 어떻게 성능에 영향을 미치는지 깊이 있게 알아보도록 하자. 단순 이론을 넘어서 Explain Plan 해석이나 인덱스 사용 시 주의사항도 함께 다룰 예정이다.
✅1. 인덱스란?
인덱스(Index)는 테이블에서 데이터를 더 빠르게 조회하기 위한 자료구조이다.
- 마치 책의 목차처럼, 원하는 데이터를 빠르게 찾을 수 있게 도와줌
- 정렬된 데이터를 참조해서 원하는 레코드로 바로 Jump하는 방식
예시 :
수천 개의 책 중에서 "A로 시작하는 단어"만 찾으려면 처음부터 훓지 않고, 목차(인덱스)를 보고 곧바로 해당 위치로 접근하듯, DB도 전체 테이블 스캔 없이 인덱스를 활용해 빠르게 접근할 수 있음
✅2. 인덱스를 왜 사용할까?
| 상황 | 인덱스 없을 때 | 인덱스 있을 때 |
| SELECT * FROM USER WHERE NAME = '홍길동' | 전체 테이블 스캔 | 인덱스를 통해 곧바로 NAME = '홍길동' 위치로 이동 |
- 성능 향상 : 특히 대용량 테이블에서 수십, 수백 배 이상 빨라질 수 있음
- WHERE 조건, JOIN, ORDER BY, GROUP BY 등에 인덱스가 있으면 효율적
✅3. 인덱스의 구조 : B-Tree
대부분의 RDBMS (Oracle, MySQL InnoDB 등)는 B-Tree 기반 인덱스를 사용한다.
- 균형 트리 구조로서, 검색/삽입/삭제 모두O(log N)의 성능 보장
- 리프 노드에 실제 레코드 주소(ROWID)가 존재
- 왼쪽에서 오른쪽으로 오름차순 정렬된 구조
📌인덱스를 타고 내려가면서 중간값 기준으로 비교 -> 빠른 탐색 가능
✅4. 인덱스 생성 예시
CREATE INDEX idx_user_name ON user(name);- NAME 컬럼에 대해 인덱스 생성
- 이후 WHERE NAME = '홍길동' 사용 시 성능 향상
✅5. 인덱스는 만능일까?
모든 쿼리에 인덱스가 도움이 되지는 않습니다!
- INSERT/UPDATE/DELETE 성능 저하 (인덱스도 갱신 필요)
- 지나치게 많은 인덱스는 오히려 부하 증가
- WHERE 조건이 범위를 넓게 잡거나 함수 연산 시 -> 인덱스 사용 못함
예)
-- 아래는 인덱스 사용 불가!
WHERE UPPER(name) = '홍길동'✅6. 실무에서 인덱스가 중요한 이유
- 대용량 테이블 (100만건 이상)에서는 Full Table Scan이 치명적
- 잘못된 인덱스로 인해 쿼리 성능이 급격히 떨어질 수 있음
- Explain Plan으로 인덱스 스캔 vs Full Scan 구분 필요
✅7. 인덱스 종류 개요
| 종류 | 설명 |
| 단일 인덱스 | 하나의 컬럼에만 적용 |
| 복합 인덱스 | 여러 컬럼을 조합 |
| 유니크 인덱스 | 중복 허용 X (PK에 기본 적용) |
| 함수 기반 인덱스 | 컬럼에 합수 적용한 결과 기반 |
| 비트맵 인덱스 | Cardinality 낮은 컬럼에 유리 |
| Reverse 키 인덱스 | 랜덤값 분산용 (전화번호 등) |
💡 마무리 정리
| 항목 | 요약 |
| 인덱스 목적 | 빠른 검색 성능 |
| 내부 구조 | B-Tree 기반 탐색 |
| 생성 시기 | WHERE 조건, JOIN 대상, ORDER BY 컬럼 |
| 주의 사항 | 너무 많은 인덱스는 오히려 부하 |
🔜 다음 포스팅에서는 인덱스 완전 정복이라는 주제로 다뤄볼 예정이다. 단일 인덱스 VS 복합 인덱스 실무에서 언제, 어떻게 적용 해야할까?