Index
3줄 요약
- Index는 테이블 전체를 훑지 않고 필요한 행을 빨리 찾기 위한 별도 자료구조지만, 쓰기 비용과 저장 공간을 함께 증가시킨다.
- 인덱스 설계의 핵심은 “어떤 컬럼에 걸까”가 아니라 “어떤 WHERE, JOIN, ORDER BY, LIMIT 패턴을 어떤 순서로 지원할까”이다.
- 실무에서는 복합 인덱스 컬럼 순서, 선택도, 정렬 방향, 커버링 가능성, 쓰기 부하, 중복 인덱스, DDL 배포 방식까지 함께 판단해야 한다.
핵심 정리
- 대부분의 RDBMS에서 기본 인덱스는 B-Tree 계열이다. 동등 조건, 범위 조건, 정렬된 탐색에 강하다.
- 인덱스가 있으면 DB는 조건에 맞는 row pointer를 빨리 찾을 수 있다. 그러나 많은 행을 읽어야 한다면 전체 스캔이 더 나을 수 있다.
- 복합 인덱스는 왼쪽부터 정렬된 구조다.
(status, created_at, id) 인덱스는 status 조건과 created_at 정렬에 강하지만, created_at만 단독으로 찾는 데 항상 유리하지는 않다.
WHERE 조건에 컬럼이 있다고 항상 인덱스를 타는 것은 아니다. 함수, 형 변환, 낮은 선택도, 선행 컬럼 누락, 넓은 범위 조건이 인덱스 활용을 방해할 수 있다.ORDER BY와 LIMIT이 있는 목록 API는 인덱스 설계가 특히 중요하다. 인덱스가 정렬까지 지원하면 DB가 많은 행을 정렬하지 않고 앞부분만 가져올 수 있다.- 인덱스는 무료가 아니다.
INSERT, UPDATE, DELETE 때마다 관련 인덱스도 갱신되고, 중복 인덱스는 쓰기 지연과 저장 공간 낭비를 만든다.
- 인덱스 추가는 코드 한 줄보다 운영 영향이 클 수 있다. 큰 테이블에서는 생성 중 lock, I/O, replica lag, 배포 시간대, 실패 시 재시도 계획을 확인해야 한다.
- 인덱스 효과는
EXPLAIN에서 index scan 이름만 보는 것으로 끝나지 않는다. 실제 읽은 row 수, sort 제거 여부, heap/table 접근량, p95/p99 변화까지 확인해야 한다.
헷갈리는 지점
- 인덱스를 많이 만들수록 조회가 항상 빨라진다고 생각하기 쉽다. 인덱스가 검색 속도를 높인다는 설명만 기억하기 때문이다.
- 핵심은 인덱스가 쓰기 비용과 옵티마이저 선택 복잡도를 늘린다는 점이다.
- 실제 쿼리 패턴과 실행 계획으로 필요한 인덱스만 유지해야 한다.
- 복합 인덱스는 포함된 컬럼이면 어떤 순서든 효과가 있다고 오해하기 쉽다. 컬럼 목록만 보기 때문이다.
- 핵심은 복합 인덱스가 선행 컬럼부터 정렬된다는 점이다.
- 동등 조건, 범위 조건, 정렬 조건의 순서로 컬럼 배치를 검토한다.
- 카디널리티가 낮은 컬럼에는 인덱스가 무조건 의미 없다고 생각하기 쉽다.
status 같은 값이 적은 컬럼만 떠올리기 때문이다.
- 핵심은 단독 인덱스와 복합 인덱스를 구분하는 것이다.
status가 낮은 선택도라도 status, created_at 목록 조회에서는 매우 유용할 수 있다.
- 인덱스가 하나라도 사용되면 좋은 계획이라고 생각하기 쉽다. 실행 계획에 index scan이 보이면 안심하기 때문이다.
- 핵심은 인덱스를 탔는지보다 몇 row를 읽고, 얼마나 정렬하고, table 접근을 얼마나 했는지가 중요하다는 점이다.
- 느린 index scan은 빠른 sequential scan보다 나쁠 수 있다.
확인 질문
- 인덱스가 조회를 빠르게 만들 수 있는 이유는 무엇인가?
- 정렬된 자료구조를 통해 조건에 맞는 위치를 빠르게 찾고, 필요한 행만 접근할 가능성을 높이기 때문이다.
- 복합 인덱스 컬럼 순서를 정할 때 가장 먼저 봐야 하는 것은 무엇인가?
- 실제 쿼리의 동등 조건, 범위 조건, 정렬 조건, LIMIT 패턴과 선행 컬럼 사용 여부를 봐야 한다.
- 인덱스를 추가하기 전에 확인해야 하는 것은 무엇인가?
- 실제 느린 쿼리, 실행 계획, 읽은 행 수, 기존 중복 인덱스, 쓰기 부하, 저장 공간, 배포 방식이다.
LIMIT 20 목록 API에 인덱스가 중요한 이유는 무엇인가?
- 조건과 정렬을 인덱스가 함께 지원하면 DB가 많은 row를 정렬한 뒤 20개를 버리는 대신, 필요한 순서대로 앞부분만 읽을 수 있기 때문이다.