피드로 돌아가기
Día 10: Le pusiste índices a todo y ahora los INSERT tardan 800ms
Dev.toDev.to
Database

불필요한 Index 제거를 통한 INSERT 성능 69% 개선 및 디스크 사용량 82% 절감

Día 10: Le pusiste índices a todo y ahora los INSERT tardan 800ms

Alejandro Lafourcade Despaigne2026년 4월 23일8intermediate

Context

쿼리 성능 향상을 위해 모든 컬럼에 Index를 생성하는 과잉 최적화 anti-pattern 발생. 이로 인해 쓰기 작업 시마다 모든 B-tree 구조를 갱신해야 하는 부하가 누적되며 INSERT 지연 시간이 800ms까지 증가한 상황.

Technical Solution

  • 실제 쿼리 패턴 분석을 통한 불필요한 Index 식별 및 제거
  • 단일 컬럼 Index 다수를 제거하고 빈번한 조회 조건인 clienteId와 fecha를 결합한 Compound Index 설계
  • 대시보드 필터링에 필수적인 estado 컬럼만 유지하여 읽기 성능 유지와 쓰기 비용 최소화 달성
  • 데이터 선택도(Selectivity) 분석을 통해 전체 데이터의 상당 부분을 반환하는 쿼리에 대한 Index 적용 배제
  • 테이블 성격(Read-heavy vs Write-heavy)에 따른 Index 전략 차별화 적용

Impact

  • 5K 레코드 INSERT 처리 속도: 1,240ms에서 380ms로 약 69% 단축
  • 디스크 점유 공간: 2.1GB에서 380MB로 약 82% 절감
  • 핵심 SELECT 쿼리 성능: 기존 5ms 수준을 동일하게 유지하여 읽기 성능 손실 없음

Key Takeaway

Index는 읽기 속도를 위해 쓰기 비용을 지불하는 Trade-off 계약이며, 가상 시나리오가 아닌 실제 실행 쿼리 기반의 정밀한 Index 설계가 시스템 전체 처리량(Throughput)을 결정함.


- pg_stat_statements(PostgreSQL) 또는 sys.statements_with_full_table_scans(MySQL)를 통한 실제 슬로우 쿼리 분석 - Index 생성 전 '해당 컬럼의 필터링 선택도가 높은가'와 '쓰기 빈도가 얼마나 높은가'를 우선 검토 - 다중 단일 Index보다 실제 조회 패턴을 반영한 Compound Index 도입 고려 - 데이터의 20% 이상을 반환하는 쿼리의 경우 Index보다 Full Table Scan이 효율적일 수 있음을 인지

원문 읽기