DB 인덱스 최적화 & 용량 절감 (2025)

0한눈에

• 대상: 수년간 운영된 마스터 DB (lab-master) — 미사용 인덱스·비효율 쿼리로 용량 비대·성능 저하.
• 핵심 증거: 실사용 쿼리 95개를 EXPLAIN 분석 → 인덱스 311개 중 224개(72%)가 불필요.
• 성과: 용량 2.6TB → 1.2TB (53.8% 절감), 초기 설치 DB 생성 12h → 6h.

1왜 했나

마스터 DB는 수년간 운영되며 인덱스가 추가되기만 하고 정리된 적이 없었다. 미사용 인덱스는 저장 용량을 잡아먹고, 쓰기 부하와 DB 초기 구성(설치 시 lab-master로부터 DB 생성) 시간을 늘린다. 비효율 쿼리(OR 남발, LIKE '%...' 등)는 인덱스를 못 타서 풀스캔을 유발했다. → 실측 기반으로 무엇을 지울지 정해야 했다.

2진행 순서

1. 운영에서 실제 사용되는 쿼리 95개 수집
2. 각 쿼리를 EXPLAIN으로 분석해 어떤 인덱스가 실제로 타는지 매핑
3. 전체 인덱스 311개 중 어디에도 안 쓰이는 224개(72%) 식별 → 삭제
4. 복합 인덱스 컬럼 순서를 실행 계획에 맞게 재구성
5. SQL 튜닝: OR → UNION 전환, LIKE 와일드카드 패턴 최적화로 인덱스 활용
6. 용량·DB 생성 시간 재측정으로 효과 검증

3온보딩 포인트

• 인덱스 정리의 1순위 근거는 실사용 쿼리의 EXPLAIN이다. "있으니 두자"가 아니라 "안 타니 지운다".
• 복합 인덱스는 개수보다 컬럼 순서가 실행 계획에 더 큰 영향을 준다.
• SQL 패턴 안티: OR 다중 조건 → UNION으로 분해, 선두 LIKE '%x'는 인덱스 불가 → 패턴 조정.
• 용량 절감은 곧 lab-master 기반 초기 DB 생성 시간 단축으로 이어진다(설치 온보딩 영향).

4공개(포트폴리오)와의 차이

공개 버전(human/portfolio/items/db-index-optimization.html)은 내부 호스트명(lab-master 등)과 내부 절차 디테일을 제거하고 문제·접근·임팩트 중심으로 일반화했다. 수치(2.6TB→1.2TB, 311/224개, 95개, 12h→6h)는 동일하게 유지. 이 내부 문서는 본인 참고/온보딩용.