10강. 인덱스의 원리와 적용 기준

?1. 이번 강의에서 해결할 문제

느릴 것 같은 모든 열에 인덱스를 추가하면 쓰기·저장 공간·유지 비용만 늘 수 있습니다. 실제 랭킹 API의 필터, 정렬, JOIN 패턴에서 필요한 인덱스 후보를 도출합니다.

✓2. 학습 목표

✓이 강의를 마치면

• B-tree가 범위 탐색과 정렬을 돕는 원리를 설명합니다.
• 단일·복합·부분 인덱스의 열 순서를 조회 조건으로 결정합니다.
• 선택도와 쓰기 비용을 포함한 인덱스 근거를 작성합니다.

◇3. 핵심 개념

PostgreSQL의 기본 B-tree 인덱스는 정렬된 키와 행 위치를 유지해 전체 테이블 대신 필요한 범위를 찾게 합니다. 복합 인덱스는 왼쪽 열부터 사용할 수 있는 조건이 중요합니다. 낮은 선택도의 단일 boolean 열은 이득이 작지만 활성 행만 담는 부분 인덱스는 효과적일 수 있습니다. 인덱스는 읽기를 돕는 대신 모든 쓰기마다 갱신됩니다.

§4. 단계별 예시

파일 경로: C:\dev\game-ranking-service\database\sql\10-indexes.sql

database/sql/10-indexes.sql

-- 플레이어의 최근 경기 목록
CREATE INDEX IF NOT EXISTS ix_results_player_game_desc
ON ranking.match_results (player_id, game_id DESC);

-- 기간별 완료 경기 조회
CREATE INDEX IF NOT EXISTS ix_games_finished_started
ON ranking.games (started_at DESC)
WHERE status = 'finished';

-- FK를 가진 쪽의 삭제·JOIN 검사 지원
CREATE INDEX IF NOT EXISTS ix_results_character
ON ranking.match_results (character_id);

SELECT schemaname, tablename, indexname, indexdef
FROM pg_indexes
WHERE schemaname = 'ranking'
ORDER BY tablename, indexname;

PowerShell · 인덱스 적용

psql -d game_ranking_dev -v ON_ERROR_STOP=1 -f .\database\sql\10-indexes.sql

§5. 동작 원리

(player_id, game_id DESC)는 특정 플레이어로 먼저 좁히고 최신 game_id 순으로 읽는 쿼리에 맞습니다. 부분 인덱스는 완료 경기만 저장해 작은 구조를 유지합니다. 단, 플래너가 인덱스보다 순차 스캔이 싸다고 판단하면 인덱스를 사용하지 않을 수 있으며 이는 오류가 아닙니다.

!6. 자주 하는 실수와 해결법

!자주 하는 실수

• 한 열마다 인덱스: 실제 WHERE·JOIN·ORDER BY 조합에서 시작합니다.
• 복합 인덱스 열 순서를 무시: 등호 필터, 범위, 정렬과 선택도를 함께 검토합니다.
• 운영 대형 테이블에 일반 CREATE INDEX: 쓰기를 오래 막을 수 있습니다. 영향과 트랜잭션 제약을 이해한 뒤 CREATE INDEX CONCURRENTLY를 검토합니다.

✎7. 직접 실습

✎직접 실습

1. 랭킹 서비스의 핵심 조회 다섯 개와 조건·정렬 열을 표로 만듭니다.
2. 각 인덱스가 돕는 쿼리와 추가 쓰기 비용을 연결합니다.
3. 중복되거나 왼쪽 접두가 겹치는 인덱스 후보를 찾아 제거 근거를 적습니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 인덱스가 SELECT를 빠르게 하면서 INSERT 비용을 늘리는 이유는 무엇인가요?
2. 복합 인덱스의 열 순서는 무엇을 기준으로 정하나요?
3. 인덱스가 있어도 순차 스캔을 선택할 수 있는 이유는 무엇인가요?

■9. 핵심 요약

■핵심 요약

인덱스는 실제 조회 패턴을 위한 정렬된 보조 구조입니다. 필터·JOIN·정렬과 데이터 분포를 근거로 설계하고, 읽기 이득과 쓰기·공간 비용을 실행 계획으로 검증합니다.