Index design ledger

인덱스는 “더 만들기”가 아니라, 읽기 이득이 쓰기 비용을 이기는지 계속 결산하는 대상입니다.

하나의 인덱스는 SELECT 경로를 줄이지만, 동시에 모든 DML과 통계·정비 작업에 비용을 추가합니다. 설계 기준은 효과가 보이는가, 중복되지 않는가, 운영 중 안전하게 바꿀 수 있는가입니다.

3-5 OLTP 시작점테이블당 인덱스 수를 작게 시작하고 관측으로 늘립니다.
20% 단편화 경고선삭제가 많은 테이블은 재구성 여부를 검토합니다.
검토 지점
읽기에서 얻는 것
쓰기·운영에서 내는 비용
판단
새 인덱스 추가 쿼리가 느릴 때
WHERE, JOIN, ORDER BY 경로가 짧아짐

탐색 범위가 줄고 정렬을 덜 수행합니다.

INSERT / UPDATE / DELETE마다 같이 갱신

쓰기 많은 테이블에서는 체감 비용이 바로 커집니다.

실행 계획과 호출 빈도까지 보고 추가

느린 쿼리 하나보다 전체 트래픽 비중이 더 중요합니다.

중복 인덱스 (a,b)와 (a)
왼쪽 접두 컬럼은 이미 같은 탐색에 사용 가능

(a,b)가 있으면 a 조건 검색을 대체할 수 있습니다.

같은 의미의 구조를 두 번 유지

저장 공간과 변경 비용만 늘어납니다.

먼저 합치거나 제거할 후보로 본다

완전히 같은 것은 DROP, 일부 다른 것은 실제 사용량으로 판단합니다.

운영 중 변경 서비스가 켜진 상태
새 조회 패턴을 빠르게 반영

API 추가나 리포트 쿼리에 맞춰 경로를 보강합니다.

생성 중 잠금, 통계 오류, 단편화

대량 변경 직후에는 옵티마이저가 낡은 통계를 볼 수 있습니다.

ONLINE / CONCURRENTLY와 통계 갱신을 함께 계획

생성 방식, 배포 시간, 롤백 절차를 같이 정합니다.

1. 추가 전에는 기존 인덱스와 겹치는지 먼저 본다

새로 만드는 것보다 중복을 줄이는 쪽이 더 안전할 때가 많습니다.

2. 미사용 인덱스는 읽기 이득 없이 쓰기 비용만 남긴다

모니터링으로 실제 사용 여부를 확인한 뒤 제거합니다.

3. 대량 변경 뒤에는 통계를 갱신한다

ANALYZE TABLE, DBMS_STATS 같은 통계 갱신이 실행 계획을 되살립니다.