언제 인덱스 — 언제 안 함

~12 min · indexes, tradeoffs, design

Level 0Scout

0 XP0/80 lessons0/10 achievements

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

인덱스는 공짜 아냐

모든 인덱스가 write 느리게 (모든 INSERT/UPDATE/DELETE 가 인덱스 업데이트) 만들고 디스크 차지. 비용보다 더 갚는 인덱스 정확히 만드는 게 기술.

인덱스 시기:

큰 테이블의 자주 WHERE, JOIN, ORDER BY 컬럼.
높은 selectivity 컬럼 (distinct 값 많은).
FK — 거의 항상 인덱스.

인덱스 안 할 때:

테이블이 작음 (수천 미만). Full scan 이 인덱스 lookup overhead 보다 빠름.
낮은 selectivity (예: boolean). Partial 인덱스 써.
필터링/join 거의 안 함.
Write-heavy + 인덱스가 hot query 에 안 쓰임.

Warning: 인덱스는 active maintenance 부담. 기존 인덱스 리뷰 (안 쓰는 거, 중복, 2 년 전 버그 fix 로 추가된 거) 가 정상 DB hygiene. SELECT name FROM sqlite_schema WHERE type='index' AND tbl_name='X' 가 audit 시작점.

Code

테이블의 기존 인덱스 audit·sql

-- 이 테이블의 user-created 인덱스
SELECT name, sql
FROM   sqlite_schema
WHERE  type = 'index'
  AND  tbl_name = 'messages'
  AND  name NOT LIKE 'sqlite_%';

-- Per-index 통계 (ANALYZE 후):
SELECT * FROM sqlite_stat1 WHERE tbl = 'messages';

External links

Query Planning

Exercise

피파의 conversations.db (또는 본인 SQLite DB) 인덱스 audit. 각 테이블마다 인덱스 list, 각각 알려진 hot query 로 정당화되는지? 중복 (composite (a,b) 가 single (a) 잉여 만듦) 있나? Keep / drop / add 추천 노트.

Progress

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

← PreviousCREATE INDEX — Single, Composite, Unique Next →EXPLAIN QUERY PLAN — 진실 읽기

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

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

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

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