데이터베이스 인덱스에 대해서 설명해주세요

대부분의 RDBMS는 B+Tree 구조를 사용합니다. Root에서 시작해 Branch를 타고 내려가 Leaf에 도달하는 트리 구조로, 모든 Leaf Node가 같은 깊이를 유지해 어떤 값을 찾아도 탐색 횟수가 동일합니다.

Leaf Node끼리 양방향 연결 리스트로 연결되어 있어 BETWEEN, >, < 같은 범위 검색도 한 번의 탐색으로 처리합니다. 이것이 B-Tree가 아닌 B+Tree를 사용하는 이유입니다.

아래에서 B+Tree의 탐색 과정을 직접 체험해 보세요.

클러스터형 인덱스는 데이터 행 자체가 인덱스 키 순서대로 물리적으로 저장됩니다. InnoDB에서 Primary Key가 바로 클러스터형 인덱스이며, 테이블당 1개만 존재할 수 있습니다. Leaf Node에 실제 데이터 행 전체가 담겨 있어 PK 조회는 단 한 번의 트리 탐색으로 완결됩니다.

비클러스터형 인덱스(Secondary Index)는 Leaf Node에 인덱스 키와 PK만 저장합니다. 조회 시 Secondary Index로 PK를 얻은 뒤 Clustered Index를 다시 탐색(Double Lookup)해야 합니다.

두 인덱스의 데이터 접근 방식을 비교해 보세요.

두 개 이상의 컬럼을 묶어 하나의 인덱스를 만들 수 있습니다. 핵심 규칙은 선두 컬럼(Leftmost Prefix): (last_name, first_name, age) 복합 인덱스는 last_name이 조건에 없으면 인덱스를 타지 못합니다.

컬럼 선택도(Selectivity)도 중요합니다. 유니크한 값이 많을수록(이메일, 주문번호 등) 인덱스 효과가 크고, 값이 몇 종류뿐인 컬럼(성별, 상태값)은 인덱스 효과가 미미합니다.

어떤 쿼리가 복합 인덱스를 타고 어떤 쿼리가 타지 못하는지 확인해 보세요.

쿼리가 필요로 하는 모든 컬럼이 인덱스에 포함되면 실제 데이터 페이지에 접근하지 않고 인덱스만으로 결과를 반환합니다. 이를 커버링 인덱스라 하며, EXPLAIN 결과의 Extra 컬럼에 Using index가 표시됩니다.

EXPLAIN의 type 컬럼은 인덱스 활용 품질을 보여주는 핵심 지표입니다. ALL(풀스캔)에서 const(PK 단건 조회)까지 6단계가 있으며, 느린 쿼리를 최적화할 때 이 값을 먼저 확인합니다.

EXPLAIN 결과를 분석하며 인덱스 활용도를 직접 확인해 보세요.

인덱스를 생성했는데도 쿼리가 느리다면 대부분 인덱스를 타지 않는 패턴을 사용하고 있습니다. 컬럼에 함수를 적용하거나, LIKE 앞 와일드카드를 쓰거나, 묵시적 형변환이 일어나면 옵티마이저가 인덱스를 무시하고 풀스캔을 선택합니다.

아래 4가지 주요 함정을 익혀두면 느린 쿼리의 원인을 빠르게 파악할 수 있습니다.

각 함정 패턴을 확인하고 올바른 쿼리 작성법을 비교해 보세요.