데이터베이스에서 인덱스는 검색 성능을 향상시키기 위한 자료구조이다. 인덱스는 책의 목차처럼, 원하는 데이터를 빠르게 찾기 위해 미리 정리해놓은 정보를 말한다. 특히 대량의 데이터 중에서 조건에 맞는 데이터를
빠르게 조회해야 할 때 인덱스가 큰 역할을 한다.

기본 개념

• 인덱스는 특정 컬럼의 값을 기반으로 정렬된 상태로 저장된 별도의 자료구조이다.
  • 기본적으로는 오름차순으로 정렬되어있다.
• 일반적으로 B-Tree 또는 Hash 구조로 구현되어있다.
  • 이는 스토리지 엔진에 따라 다른데 MySQL에서 사용하는 InnoDB의 경우 B+ Tree로 되어있다.
• 테이블의 실제 데이터를 참조하는 포인터(주소)도 같이 저장되어 있어, 인덱스를 통해 빠르게 원하는 데이터를 찾아갈 수 있다.

인덱스가 정렬되어 있는 이유

MySQL(InnoDB)에서 인덱스는 B+ Tree 구조로 되어있는데, 이 트리는 자동으로 데이터를 정렬된 순서로 저장하고 유지한다. 정렬된 자료구조는 다음과 같은 작업을 빠르게 동작할 수 있도록 해준다.

작업 유형	정렬이 중요한 이유
WHERE age = 20	중간 지점부터 빠르게 탐색 사능하다 (Binary Search 처럼)
WHERE age BETWEEN 20 AND 30	범위 검색 시 리프 노드를 순차 탐색한다
ORDER BY age	이미 정렬되어 있어 별도의 정렬 연산이 필요 없다
GROUP BY	그룹이 붙어 있어서 정렬 없이 처리 가능하다

오름차순 내림차순을 지정하는 방법

MySQL 8.0 부터는 명시적으로 인덱스의 오름차순/내림차순을 지정할 수 있다.

CREATE INDEX idx_age_asc ON users(age ASC);
CREATE INDEX idx_age_desc ON users(age DESC);

하지만 B+ Tree 자체는 양방향 순회가 가능하기 때문에 대부분의 경우 오름차순 인덱스 하나로도 내림차순 쿼리를 처리할 수 있다.

• 하지만 복합 인덱스에서는 순서가 매우 중요할 수 있다.

인덱스의 종류

종류	설명
기본 인덱스, Primary Index	기본 키에 자동으로 생성되는 인덱스
보조 인덱스, Secondary/Non-clustered Index	기본 키 외의 컬럼에 사용자가 수동으로 생성하는 인덱스
유니크 인덱스, Unique Index	중복을 허용하지 않는 인덱스
복합 인덱스, Composite Index	여러 개의 컬럼을 묶어서 만든 인덱스
클러스터형 인덱스, Clustered Index	데이터 자체가 인덱스 순서대로 저장되는 방식(MySQL InnoDB는 기본적으로 클러스터형 인덱스를 사용한다)
비트맵 인덱스, Bitmap Index	비트맵 형태로 인덱싱하는 인덱스(OLAP, 조건이 다양한 분석에 유리하다)
전문검색 인덱스, Full Text Index	텍스트 검색용 인덱스(LIKE, MATCH AGAINST 등)

• 비트맵 인덱스는 MySQL(InnoDB)에서는 지원하지 않는다.

인덱스의 장점

1. 검색 속도 향상: WHERE, JOIN, ORDER BY, GROUP BY 에서 빠른 조회가 가능하다.
2. 정렬 비용 감소: ORDER BY 시 이미 정렬된 구조 덕분에 성능이 개선된다.
3. 고유성 보장: UNIQUE 인덱스로 중복 방지가 가능하다.

인덱스의 단점

1. 쓰기 성능 저하: INSERT, UPDATE, DELETE 시 인덱스도 갱신해야 하므로 부하가 발생한다.
2. 디스크 공간 소모: 인덱스를 저장하는 데 추가 공간이 필요하다.
3. 잘못된 인덱스는 성능을 저하시킨다: 불필요하거나 중복된 인덱스는 오히려 쿼리 성능을 낮출 수 있다.

인덱스가 잘 작동하는 경우

• WHERE 절에 자주 등장하는 컬럼.
• JOIN에 자주 사용되는 컬럼.
• 정렬, 그룹화에 자주 사용되는 컬럼.
• 테이블이 크고, 조건에 맞는 결과가 적을 때(선택도가 높을 때)

인덱스 사용 예시: MySQL

회원가입 시에 이메일 중복 검사가 필요하여 데이터베이스에 조회를 해야 할 때 아래와 같은 인덱스를 생성할 시 빠르게 조회할 수 있다.

-- 인덱스 생성
CREATE INDEX idx_user_email ON users (email);

-- 인덱스 보기
SHOW INDEX FROM users;

-- 인덱스 삭제
DROP INDEX idx_user_email ON users;

실행 계획(Execution Plan)과 인덱스

쿼리 성능을 분석할 때는 EXPLAIN 키워드를 사용하여 인덱스가 실제로 사용되었는지 확인해야 한다.

EXPLAIN
SELECT *
FROM users
FORCE INDEX (idx_user_email) -- row수가 적을 때는 강제적으로 인덱스를 사용하도록 설정
WHERE email = 'rlarlgus0206@naver.com';

요약

• 목적: 검색 성능 향상
• 작동 방식: 컬럼 값을 기준으로 정렬된 자료구조로 구성
• 장점: 빠른 조회, 효율적인 정렬
• 단점: 쓰기 성능 저하, 디스크 공간 차지
• 주의할 점: 자주 사용하는 컬럼에만 적용해야 효과적이다