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