DB 인덱스는 특정 컬럼 값으로 행을 빨리 찾도록 테이블 옆에 따로 유지하는 보조 자료구조(auxiliary data structure)다. 관계형 DB의 기본 인덱스는 정렬된 균형 트리(B-tree 계열)라서, 전체를 훑지 않고 트리를 따라 내려가 원하는 행에 닿는다.
CREATE INDEX idx_orders_customer ON orders (customer_id);
SELECT * FROM orders WHERE customer_id = 42; -- 풀스캔 대신 인덱스 탐색얻는 것과 내는 것
- 조회가 빨라진다: 동등 비교, 범위 조건, 정렬(
ORDER BY)에 쓰인다 - 쓰기가 느려진다: INSERT·UPDATE·DELETE 때마다 인덱스도 함께 고쳐야 한다
- 공간을 더 쓴다: 인덱스 자체가 디스크와 메모리를 차지한다
- 인덱스가 너무 많으면 쓰기 부담만 커지고 옵티마이저(query optimizer) 선택도 흔들린다
잘 안 타는 경우
LIKE '%검색어'처럼 앞이 와일드카드인 패턴 → 전문 검색은 검색 엔진으로- 컬럼에 함수를 씌운 조건(
WHERE lower(email) = ...) → 함수 기반 인덱스(expression index)를 따로 만든다 - 복합 인덱스(composite index)
(a, b)에서b만으로 찾는 경우 → 앞 컬럼부터 쓰여야 한다 - 값의 종류가 적은 컬럼(성별 등)은 효과가 작다. 실행 계획(execution plan,
EXPLAIN)으로 확인한다
일반 법칙
읽기를 빠르게 하는 거의 모든 기법(인덱스, 캐시, 비정규화(denormalization), 읽기 복제본)은 쓰기 비용이나 정합성으로 값을 치른다.
같은 DB 안의 인덱스는 "쓰기 속도와 용량"으로, 검색 엔진·캐시·복제본처럼 저장소를 하나 더 두는 방법은 "동기화와 정합성"으로 값을 낸다(최종 일관성). 무작정 다 걸기보다 측정한 뒤 필요한 곳에 거는 것이 섣부른 최적화를 피하는 길이다. 트리 구조의 원리는 이진 탐색 트리와 이진 탐색를 본다.
출처: PostgreSQL 문서: Indexes Introduction · Multicolumn Indexes