DB 인덱스 최적화 & 용량 53% 절감

수년간 운영되며 비대해진 중앙 운영 DB를, 실사용 쿼리 분석 기반으로 불필요 인덱스를 걷어내고 SQL을 튜닝해 용량과 성능을 동시에 개선

기간2025

소속래브라도랩스(LabradorLabs)

역할데이터 엔지니어 · 인덱스 진단 및 최적화 주도

MySQLEXPLAINIndex TuningSQL OptimizationQuery Analysis

0작업자의 메모

이 작업에서 제일 조심한 부분은 “인덱스를 많이 지웠다”가 아니라 “지워도 되는지 증명했다”였습니다. 운영 DB에서 감으로 인덱스를 건드리는 순간 성능 문제는 더 커질 수 있기 때문입니다.

실제 쿼리 95개와 EXPLAIN 결과로 사용 여부를 확인한 뒤에야 삭제와 재구성을 진행했습니다. 그래서 2.6TB에서 1.2TB로 줄어든 결과보다, 그 판단 과정을 남긴 것이 더 중요했습니다.

수년간 운영되어 온 중앙 운영 DB는 그동안 누적된 미사용 인덱스와 비효율 쿼리로 인해 저장 용량이 비대해지고 전반적인 성능이 저하된 상태였습니다.

① 수집실제 사용 쿼리 95개 확보

→

② 분석EXPLAIN으로 인덱스 사용 여부 검증

→

③ 정리불필요 인덱스 삭제·복합 인덱스 재구성

→

④ 튜닝쿼리 재작성으로 인덱스 활용 극대화

실제 사용되는 쿼리 95개를 EXPLAIN으로 분석해 전체 인덱스 311개 중 224개(72%)가 실행 계획에서 전혀 쓰이지 않음을 정량적으로 증명
불필요 인덱스를 삭제하고 복합 인덱스의 컬럼 순서를 실제 실행 계획에 맞게 재구성
SQL 튜닝: OR 조건을 UNION으로 전환하고 LIKE 와일드카드 패턴을 인덱스가 타도록 최적화

핵심은 "인덱스를 줄인 것"이 아니라, 추측 대신 실측 실행 계획을 근거로 의사결정한 것입니다.

DB 용량 53.8% 절감 — 2.6TB → 1.2TB

초기 설치 시간 절반 — DB 생성 12시간 → 6시간

비용 절감 — 저장 자원 축소로 운영 비용에 직접 기여

서비스 품질 향상 — 쿼리 효율 개선으로 응답 성능 개선

데이터 엔지니어로서 쿼리 수집 → 실행 계획 분석 → 인덱스 정리 → SQL 튜닝의 전 과정을 단독으로 수행했습니다. 운영 중인 중앙 운영 DB를 다루는 만큼, 실제 사용 패턴을 근거로 안전하게 변경 범위를 좁혀가며 진행했습니다.

결과적으로 용량·비용·성능을 동시에 개선했고 이후 정기적인 인덱스 점검 기준의 토대를 마련했습니다.