본문 바로가기
C.W.K.
Stream
Lesson 03 of 10 · published

언제 인덱스 — 언제 안 함

~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가 높은 컬럼.
  • FK. 이건 거의 무조건 붙여.

반대로 안 붙이는 게 맞을 때도 있어.

  • 테이블이 작을 때. 수천 개도 안 되면 전부 훑는 게 인덱스를 타는 것보다 빨라.
  • selectivity가 낮을 때. boolean 같은 컬럼이 그래. 이럴 땐 partial 인덱스를 써.
  • 그 컬럼으로 거의 거르지도 join하지도 않을 때.
  • write가 많은데 그 인덱스가 뜨거운 query에서 안 쓰일 때.
Warning: 인덱스는 계속 손봐줘야 하는 짐이야. 안 쓰는 인덱스, 겹치는 인덱스, 2년 전 버그 하나 때문에 급하게 붙인 인덱스를 다시 들여다보는 게 정상적인 DB 관리야. SELECT name FROM sqlite_schema WHERE type='index' AND tbl_name='X'가 그 점검의 출발점이고.

Code

테이블에 이미 걸린 인덱스 점검·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

Exercise

피파의 conversations.db든 네가 가진 SQLite DB든 하나 골라서 인덱스를 점검해봐. 테이블마다 인덱스를 나열하고, 각각이 실제로 도는 뜨거운 query로 정당화되는지 따져. composite (a,b)가 있어서 single (a)가 필요 없어진 것처럼 겹치는 게 있는지도 보고. 남길 것, 지울 것, 새로 만들 것을 정리해서 노트로 남겨.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인 — 댓글을 남기려면 로그인해 주세요.

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