인덱스의 단점 — 언제 인덱스를 만들지 말아야 하나

핵심 요약

인덱스는 조회 속도를 극적으로 올리지만 공짜가 아니다. 데이터가 추가·수정·삭제될 때마다 인덱스도 갱신해야 하므로 쓰기가 느려지고, 저장공간을 더 쓰며, 잘못 만들면 옵티마이저가 안 쓰기도 한다. "느리면 인덱스"가 아니라 "필요한 곳에만"이 원칙이다.

1. 인덱스의 비용

2. 인덱스를 만들지 말아야 할 때

• 쓰기가 압도적으로 많은 테이블 — 로그·이벤트 적재 테이블에 인덱스를 많이 걸면 적재가 느려진다
• 카디널리티가 낮은 컬럼 — 성별(남/여), 불리언처럼 값 종류가 적으면 인덱스 효과가 미미(전체의 절반을 걸러도 결국 대부분을 읽음)
• 작은 테이블 — 수백 행이면 풀스캔이 인덱스보다 빠를 수 있다
• 거의 조회에 안 쓰이는 컬럼 — 쓰지도 않는 인덱스는 부담만 된다

3. "안 타는 인덱스"의 함정

• 컬럼에 함수·연산을 쓰면 인덱스가 무시된다 — WHERE YEAR(created_at) = 2026은 인덱스 못 탐. 범위 조건(>= '2026-01-01')으로 바꿔라.
• 복합 인덱스는 컬럼 순서가 중요 — 선두 컬럼 조건이 없으면 안 탄다.
• 옵티마이저가 "풀스캔이 더 싸다"고 판단하면 인덱스가 있어도 안 쓴다(통계 문제일 수도).

4. 실무 지침

• 실제 느린 쿼리를 EXPLAIN으로 확인하고, 그 쿼리가 쓰는 컬럼에만 인덱스를 추가
• 안 쓰는 인덱스는 주기적으로 찾아 제거(대부분 DB가 인덱스 사용 통계를 제공)
• "혹시 몰라서" 다는 인덱스가 쌓이면 쓰기 성능을 갉아먹는다

자주 묻는 질문

인덱스는 많을수록 좋은 거 아닌가요?

조회만 보면 유리해 보이지만, 각 인덱스는 쓰기 때마다 갱신 비용을 더합니다. 인덱스가 10개인 테이블은 INSERT 한 번에 인덱스 10개를 갱신합니다. 조회 패턴에 실제로 필요한 것만 두는 게 균형입니다.

카디널리티가 낮으면 왜 인덱스가 소용없나요?

값 종류가 적으면(예: 상태 3종) 조건으로 걸러도 여전히 많은 행이 남아, 인덱스로 찾은 뒤 테이블을 다시 읽는 비용이 풀스캔과 비슷하거나 더 큽니다. 옵티마이저가 아예 인덱스를 무시하기도 합니다.

인덱스를 만들었는데 안 타요.

조건 컬럼에 함수를 씌웠거나, 복합 인덱스의 선두 컬럼을 조건에서 뺐거나, 통계가 낡아 옵티마이저가 오판하는 경우가 흔합니다. EXPLAIN으로 확인하고, 필요하면 통계를 갱신(ANALYZE)하세요.