인덱싱
인덱스는 책 뒤의 색인과 같다: 데이터베이스가 모든 행을 스캔하는 대신 일치하는 행으로 곧장 점프하게 해준다. 인덱스가 없으면 데이터가 늘수록 쿼리가 느려진다 — 100행에서는 괜찮지만 1,000,000행에서는 고통스럽다.
인덱스가 없으면 데이터베이스는 모든 행을 차례로 확인하고, 있으면 일치하는 곳으로 곧장 점프한다 — 책 색인이 처음부터 끝까지 읽는 대신 맞는 페이지로 보내주는 것과 같다:
NO INDEX (Seq Scan) WITH INDEX (Index Scan)
모든 row 를 하나씩 읽음 매칭으로 바로 점프
┌─────────────────────┐ ┌─────────────┐
│ row 1 ✗ │ │ INDEX │
│ row 2 ✗ │ │ author_id │
│ row 3 ✓ 일치 │ ◀──────┐ │ ──┬── │
│ row 4 ✗ │ │ └─────┼───────┘
│ ... (1,000,000) │ │ ▼
│ row N ✓ 일치 │ └──▶ rows 3, 998 ✓
└─────────────────────┘ 백만 번 아닌 몇 번의 점프
실용적인 지침:
- 자주 필터하거나 조인하는 컬럼에 인덱스를 걸어라 (예:
author_id,email). - 기본 키는 자동으로 인덱싱된다.
- 모든 것에 인덱스를 걸지 말라 — 인덱스 하나하나가 읽기는 빠르게 하지만 쓰기는 느리게 하고 공간을 쓴다.
- 모든 컬럼에 선제적으로 거는 대신, 느린 쿼리를 봤을 때 인덱스를 추가하라.
인덱스가 도움이 되는지 알아내는 정직한 방법은 추측이 아니라 데이터베이스에게 물어보는 것이다. 모든 엔진에는 사용할 계획을 보여주는 EXPLAIN(Postgres에서는 EXPLAIN ANALYZE)이 있다:
EXPLAIN ANALYZE
SELECT * FROM posts WHERE author_id = '...';
큰 테이블에서 출력이 Seq Scan이라고 한다면, 데이터베이스가 모든 행을 읽고 있다는 뜻이다 — 인덱스가 도움이 되리라는 신호다. 하나를 추가하면 Index Scan으로 바뀌어야 한다. 이것은 AI에게 넘기기 좋은 작업이다: 느린 쿼리와 EXPLAIN 출력을 붙여 넣고, 어떤 인덱스를 추가해야 하는지와 그 이유를 물어라. 당신은 인덱스 이론을 외워서가 아니라 답을 이해함으로써 통제를 유지한다.