인덱스는 공짜가 아니다. 쓰기 비용을 미래로 넘긴다

1. 쓰기 비용이 바로 늘어납니다

• INSERT / UPDATE / DELETE 시 테이블 + 모든 인덱스를 같이 수정
• 인덱스 많을수록
  • 트랜잭션 시간 증가
  • 락 유지 시간 증가
  • TPS 하락

👉 쓰기 많은 테이블에 인덱스 남발 = 성능 하락 보증수표

---

2. 디스크 & 메모리 비용

• 인덱스는 보조 구조물
• 실제로는
  • 데이터보다 인덱스가 더 큰 경우도 흔함
• 버퍼 캐시 점유
  • 인덱스가 캐시 먹으면
  • 정작 필요한 데이터 페이지가 밀려남

👉 “조회 빨라짐” 대신 메모리 경쟁 발생

---

3. 옵티마이저 판단 비용

• 인덱스가 많을수록
  • 실행계획 탐색 비용 증가
  • 잘못된 인덱스 선택 확률 증가
• 특히
  • 컬럼 카디널리티 낮은 인덱스
  • 조건 순서 어정쩡한 복합 인덱스

👉 있다고 쓰는 게 아니라, 맞아야 씁니다

---

4. 인덱스는 ‘쿼리 계약’이다

인덱스 하나 추가 =

“이 쿼리는 앞으로도 중요하다”라는 운영 계약

• 쿼리 없어졌는데 인덱스는 남아 있음
• 요구사항 바뀌었는데 인덱스 구조는 과거 기준

👉 기술 부채 중에서도 가장 조용히 쌓이는 부채

---

5. 그래서 실무 원칙은 이겁니다

❌ 이렇게 하면 안 됨

• “혹시 모르니까”
• “느릴 것 같아서”
• “PK 외엔 다 인덱스”

✅ 이렇게 합니다

• 실제 슬로우 쿼리 기준
• WHERE + ORDER BY + JOIN 패턴 기준
• 카디널리티 높은 컬럼 우선
• 복합 인덱스는 순서가 핵심
• 쓰기 많은 테이블은 최소 인덱스

---

한 줄 요약 (현장 멘트용)

인덱스는 성능 옵션이 아니라, 쓰기·메모리·운영 비용을 지불하고 사는 구조다.