Stream

Lesson 03 of 10 · published

PostgreSQL 이 인덱스 쓰는 때

~14 min · indexes, planner

Level 0스키마 새싹

0 XP0/86 lessons0/10 achievements

0/120 XP to next level120 XP to go0% complete

인덱스 쓸 수 있는 모든 쿼리가 쓰는 거 아님

Planner 가 추정 비용 기반 가장 싼 plan 고름. 가끔 sequential scan 이 더 싸다고 정확히 결정 — 테이블 작거나, 쿼리가 행 대부분 반환, 통계 잘못. Planner 가 언제 인덱스 고르고 (그리고 거절하는지) 이해가 성능 작업의 절반.

Selectivity

WHERE 가 행 1% 로 좁히면 인덱스가 극적으로 빠름. 50% 로 좁히면 sequential scan 이 보통 더 쌈 (random 인덱스 lookup + heap fetch 가 sequential scan 이기는 건 인덱스가 행 적게 반환할 때만).

인덱스 스킵되는 흔한 이유

컬럼에 함수: WHERE LOWER(email) = 'x' 가 email 의 plain 인덱스 못 씀. Expression 인덱스 또는 pg_trgm.
타입 불일치: WHERE numeric_col = '123' 이 인덱스 무력화하는 cast 강제 가능.
선행 wildcard: WHERE name LIKE '%foo' 가 B-tree 못 씀.
혼합 컬럼 OR: WHERE a = 1 OR b = 2 가 보통 Bitmap OR plan 또는 별도 인덱스 두 개 필요.
Stale 통계: 큰 로드 후 ANALYZE — planner 가 데이터 모양 알게.

Code

EXPLAIN ANALYZE — 디버깅 창·sql

EXPLAIN (ANALYZE, BUFFERS, SETTINGS)
SELECT id, name FROM users WHERE email = 'alice@example.com';
-- Index Scan? 좋음. 1M 행 테이블에 Seq Scan? 나쁨 — 조사.

컬럼에 함수 = 인덱스 죽임·sql

-- users_email_idx 안 씀
SELECT * FROM users WHERE LOWER(email) = 'alice@example.com';

-- 수정: expression 인덱스
CREATE INDEX users_lower_email_idx ON users (LOWER(email));

-- 같은 쿼리가 새 인덱스 사용.

ANALYZE 로 planner 도움·sql

-- 큰 import 또는 스키마 변경 후
ANALYZE users;          -- 테이블 한 개 통계 갱신
ANALYZE;                -- 전체 DB 통계 갱신

External links

PostgreSQL EXPLAIN

Exercise

프로젝트에 느릴 거 같은 쿼리 찾기. EXPLAIN ANALYZE. Seq Scan 보면: 테이블 작음? 낮은 selectivity? 컬럼에 함수? 실제 원인 다루는 인덱스 추가; 재실행; 속도 향상 문서화.

Progress

Progress is local-only — sign in to sync across devices.

← PreviousB-tree: 기본 일꾼 Next →Composite 인덱스

이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)

로그인 — 댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.