← 기술 목록으로
DB 인덱스 최적화 & 용량 53% 절감
수년간 운영되며 비대해진 수집 DB와 고객사 배포용 DB의 인덱스를, 사용 주체별 쿼리 전수 조사를 근거로 걷어내고 SQL을 튜닝해, 배포용 DB 2.6TB를 1.2TB로, 수집 DB 9.6TB를 4TB로 줄인 작업
기간2025
소속래브라도랩스(LabradorLabs)
역할데이터 엔지니어 · 인덱스 진단 및 최적화 주도
MySQLEXPLAINIndex TuningSQL OptimizationQuery Analysis
0삭제보다 사용 확인에 시간을 더 쓴 기준
인덱스 개수를 줄이는 일보다 삭제 후보가 실제 쿼리에서 쓰이지 않는지 확인하는 데 시간을 더 썼습니다. 운영 DB에서 사용 여부를 보지 않고 인덱스를 건드리면 성능 문제가 더 커질 수 있기 때문입니다.
수집 DB는 크롤러가 실행하는 쿼리를, 배포용 DB는 분석 엔진이 실행하는 쿼리 95개를 전수로 모아 EXPLAIN으로 사용 여부를 확인한 뒤에야 삭제와 재구성을 진행했습니다. 이 확인 절차는 이후 정기 인덱스 점검 기준으로 그대로 씁니다.
1배경
수년간 운영되어 온 수집 DB와 고객사 배포용 DB는 누적된 미사용 인덱스와 비효율 쿼리로 저장 용량이 비대해지고 전반적인 성능이 저하된 상태였습니다. 두 DB는 사용 주체가 달라(크롤러 / 분석 엔진) 정리 기준도 나눠서 세웠습니다.
- 인덱스는 한 번 만들면 계속 쌓이기만 할 뿐, 정말 쓰이는지 검증된 적이 없었음
- 불필요한 인덱스는 저장 공간 낭비와 함께 쓰기 성능·DB 초기 구성 시간에 부담을 가중
- 정리 기준은 실제 사용 데이터와 실행 계획으로 설정
2접근
① 수집사용 주체별 쿼리 전수 확보
→
② 분석EXPLAIN으로 인덱스 사용 여부 검증
→
③ 정리불필요 인덱스 삭제·복합 인덱스 재구성
→
④ 튜닝쿼리 재작성으로 인덱스를 타게 재작성
- 배포용 DB는 분석 엔진이 실행하는 쿼리 95개를
EXPLAIN으로 전수 분석해 인덱스 311개 중 224개(72%)가 실행 계획에서 전혀 쓰이지 않음을 확인
- 수집 DB는 크롤러가 실행하는 쿼리를 전수 조사해 미사용 인덱스와 더 이상 쓰지 않는 레거시 테이블을 정리
- 불필요 인덱스를 삭제하고 복합 인덱스의 컬럼 순서를 실제 실행 계획에 맞게 재구성
- SQL 튜닝:
OR 조건을 UNION으로 전환하고 LIKE 와일드카드 패턴을 인덱스가 타도록 최적화
실측 실행 계획을 근거로 삭제와 재구성을 결정했습니다.
3결과
수집 DB 9.6TB → 4TB — 크롤러 쿼리 전수 조사로 미사용 인덱스·레거시 테이블 정리
배포용 DB 2.6TB → 1.2TB — 분석 엔진 쿼리 95개 전수 분석으로 53.8% 절감
초기 설치 시간 절반 — 고객사 온프레미스 DB 생성 12시간 → 6시간
정리 기준 존치 — 실측 실행 계획 기반의 정기 인덱스 점검 기준으로 남김
4역할
운영 쿼리를 모아 실행 계획과 인덱스 사용 여부를 확인했습니다. 미사용 인덱스와 레거시 테이블을 추린 뒤 SQL을 손봤고, 실제 삭제 범위와 적용 순서는 팀 리뷰를 거쳐 확정했습니다.
이 조사 방식은 이후 정기적인 인덱스 점검 기준으로 남겼습니다.