쉬운 설명
수백만 행짜리 표에서 '이메일이 abc@example.com인 사용자'를 찾는 일은, 인덱스가 없으면 한 행씩 처음부터 끝까지 다 살펴봐야 합니다(풀 스캔). 인덱스를 만들어 두면 책 뒤 색인을 보듯 즉시 해당 위치로 점프해 찾을 수 있습니다.
내부적으로는 B-Tree(균형 트리), 해시, 비트맵 같은 자료구조가 쓰입니다. 가장 흔한 B-Tree 인덱스는 '값과 그 값이 있는 행 위치'를 트리 모양으로 정렬해 둡니다. 범위 검색('나이 30~40 사이'), 정렬, 부분 매칭에 두루 강해 대부분의 RDBMS의 기본 선택지입니다.
빠른 검색의 대가로 두 가지를 지불합니다. ① 저장 공간이 더 듭니다(인덱스는 별도 데이터). ② 데이터를 쓰거나 수정할 때 인덱스도 함께 갱신해야 해서 쓰기가 약간 느려집니다. 그래서 모든 컬럼에 인덱스를 거는 건 오히려 손해입니다. '자주 검색·정렬하는 컬럼'에 선별적으로 거는 게 원칙입니다.
자주 막히는 부분: 인덱스가 있다고 무조건 빨라지는 게 아닙니다. WHERE 절이 함수로 컬럼을 감싸거나(예: WHERE LOWER(email) = ...), LIKE '%검색어'처럼 와일드카드가 앞에 오면 인덱스가 쓰이지 못합니다. 또 데이터의 종류 수가 적은 컬럼(예: '성별')에 인덱스를 걸면 거의 효과가 없습니다. 쿼리 플랜(EXPLAIN)을 보고 인덱스가 실제로 동작하는지 확인하는 습관이 필요합니다.
최근 흐름: 단순한 단일 컬럼 인덱스를 넘어 복합 인덱스(여러 컬럼을 한 인덱스로), 부분 인덱스(특정 조건의 행만), 함수 기반 인덱스(LOWER(email) 같은 표현식에 직접 인덱스)가 흔합니다. 또 검색·텍스트 분석에는 전문(full-text) 인덱스나 별도의 검색 엔진(Elasticsearch·Meilisearch)을 함께 씁니다.
비유로 보면
인덱스는 두꺼운 책 뒤에 붙은 색인과 같습니다. 색인이 없으면 '강아지'라는 단어를 찾기 위해 첫 페이지부터 끝까지 다 봐야 하지만, 색인이 있으면 'ㄱ' 항목에서 즉시 페이지로 점프할 수 있습니다. 색인이 두꺼울수록 책 자체가 두꺼워지지만, 찾기는 즉시 빨라집니다.
어디에서 만나나
모든 관계형 DB(PostgreSQL·MySQL·Oracle·SQL Server)의 기본 도구. NoSQL(MongoDB·Cassandra)에도 비슷한 기능이 있습니다. 검색·이메일 조회·정렬이 잦은 모든 테이블에 인덱스가 깔립니다. 검색 엔진은 인덱스를 더 정교하게 다루는 별도 시스템이라고 볼 수 있습니다.
작은 예시
회원 1천만 명짜리 테이블에서 'username = 'kim'인 회원을 찾는' 쿼리가 인덱스 없이는 3초, username에 인덱스를 만든 뒤로는 5ms 안에 끝납니다. 같은 로직, 같은 데이터인데 응답 시간이 600배 차이 납니다.
자주 하는 오해
한 줄 정리
인덱스는 '책의 색인'입니다. 많이 만든다고 책이 좋아지지는 않습니다. 자주 찾는 단어만 잘 정리된 색인이 가장 유용합니다.