인덱스 기초

🎯 학습 목표

이 강을 마치면 인덱스가 무엇이고 어떤 원리로 조회 속도를 높이는지 설명할 수 있습니다. CREATE INDEX로 직접 인덱스를 생성하고, EXPLAIN QUERY PLAN으로 쿼리가 인덱스를 사용하는지 확인할 수 있습니다. 인덱스가 효과적인 경우와 역효과가 나는 경우를 구분해 언제 인덱스를 생성해야 할지 판단할 수 있게 됩니다.

💡 인덱스가 필요한 이유

이 섹션에서는 인덱스 없이 데이터를 검색할 때의 문제점과 인덱스의 역할을 살펴보겠습니다.

테이블에 100만 개의 행이 있다고 가정합니다. WHERE email = 'kim@example.com'으로 특정 회원을 찾으려면 어떻게 할까요? 인덱스가 없다면 데이터베이스는 처음부터 끝까지 모든 100만 개 행을 하나씩 검사해야 합니다. 이것을 전체 테이블 스캔(Full Table Scan)이라고 합니다. 행 수가 많을수록 시간이 선형으로 늘어납니다.

인덱스(Index)는 책의 색인처럼 특정 열의 값과 해당 행의 위치를 미리 정렬해 저장해 둔 별도 데이터 구조입니다. 색인을 보고 'ㅋ' 항목에서 '클린 코드'를 바로 찾는 것처럼, 인덱스를 통해 수백만 행 중에서 원하는 행을 몇 단계만에 찾을 수 있습니다.

일반적으로 데이터베이스 인덱스는 B-트리(B-Tree) 구조를 사용합니다. 값들이 정렬된 트리 구조로 저장되어 있어, 이진 탐색처럼 검색 범위를 절반씩 줄여나갑니다. 100만 개 행에서 원하는 값을 찾는 데 약 20번의 비교로 충분합니다(log₂(1,000,000) ≈ 20).

🏗️ CREATE INDEX — 인덱스 생성

이 섹션에서는 인덱스를 직접 생성하는 방법을 살펴보겠습니다.

PRIMARY KEY와 UNIQUE 제약에는 자동으로 인덱스가 생성됩니다. 그 외의 열에 인덱스가 필요하면 직접 생성합니다.

-- 단일 열 인덱스
CREATE INDEX idx_members_grade ON members(grade);
CREATE INDEX idx_orders_member ON orders(member_id);
CREATE INDEX idx_orders_date   ON orders(order_date);
CREATE INDEX idx_books_category ON books(category);

-- 복합 인덱스 (여러 열 조합)
CREATE INDEX idx_orders_member_date ON orders(member_id, order_date);

-- 인덱스 삭제
DROP INDEX IF EXISTS idx_members_grade;

인덱스 이름은 보통 idx_테이블명_열명 형식을 사용합니다. 같은 DB 안에서 유일해야 합니다.

복합 인덱스는 두 개 이상의 열을 묶어 만든 인덱스입니다. idx_orders_member_date는 member_id와 order_date를 함께 조건으로 쓰는 쿼리에서 효과적입니다. 중요한 점은 복합 인덱스에서 열 순서가 중요합니다. WHERE member_id = 1 AND order_date >= '2024-01-01'은 인덱스를 활용하지만, WHERE order_date >= '2024-01-01'만 쓰면 이 복합 인덱스를 쓰지 못합니다(앞의 열 기준으로 구성되기 때문). 자주 조회하는 순서대로 열을 나열하는 것이 원칙입니다.

🔍 EXPLAIN QUERY PLAN — 인덱스 사용 확인

이 섹션에서는 쿼리가 인덱스를 실제로 사용하는지 확인하는 방법을 살펴보겠습니다.

인덱스를 만들었다고 해서 항상 사용되는 것은 아닙니다. 데이터베이스 쿼리 최적화기가 전체 스캔이 더 빠르다고 판단하면 인덱스를 사용하지 않습니다. 실제로 어떤 방식으로 쿼리가 실행되는지 확인하려면 EXPLAIN QUERY PLAN을 씁니다.

-- 인덱스 없이 조회
EXPLAIN QUERY PLAN
SELECT * FROM members WHERE grade = 'VIP';
-- 결과: SCAN members (전체 스캔)

-- 인덱스 생성 후 다시 확인
CREATE INDEX idx_members_grade ON members(grade);
EXPLAIN QUERY PLAN
SELECT * FROM members WHERE grade = 'VIP';
-- 결과: SEARCH members USING INDEX idx_members_grade (인덱스 사용)

-- 날짜 범위 조회
EXPLAIN QUERY PLAN
SELECT * FROM orders WHERE order_date >= '2024-05-01';
-- idx_orders_date 있으면: SEARCH orders USING INDEX idx_orders_date

결과에 SCAN이 나오면 전체 테이블 스캔, SEARCH USING INDEX가 나오면 인덱스를 활용한 효율적인 검색입니다. 실무에서 느린 쿼리를 최적화할 때 EXPLAIN은 첫 번째로 확인하는 도구입니다.

⚠️ 인덱스의 부작용과 언제 쓸까

이 섹션에서는 인덱스가 항상 좋은 것은 아닌 이유와 인덱스가 효과적인 상황을 살펴보겠습니다.

인덱스는 조회(SELECT) 속도를 높이지만 부작용도 있습니다.

첫째로 INSERT·UPDATE·DELETE 속도가 느려집니다. 데이터가 추가·변경·삭제될 때마다 인덱스도 함께 갱신해야 합니다. 인덱스가 많을수록 DML이 느려집니다.

둘째로 저장 공간을 추가로 사용합니다. 인덱스는 별도의 데이터 구조이므로 테이블 크기 외에 추가 공간이 필요합니다. 데이터가 많고 인덱스가 많으면 상당한 저장 공간을 차지합니다.

셋째로 소규모 테이블에서는 인덱스가 오히려 느릴 수 있습니다. 데이터가 수천 개 이하면 전체 스캔이 인덱스 조회보다 빠를 수 있습니다. 쿼리 최적화기가 이를 판단해 자동으로 결정합니다.

인덱스가 효과적인 상황입니다.

효과적인 경우	효과 없거나 불필요한 경우
WHERE 조건에 자주 쓰이는 열	행 수가 적은 테이블(수천 개 이하)
JOIN의 ON 조건으로 쓰이는 외래키 열	카디널리티가 낮은 열 (예: 성별 M/F)
ORDER BY에 자주 쓰이는 열	LIKE '%값%'처럼 앞에 %가 오는 패턴
카디널리티(유일값 수)가 높은 열	자주 변경되는 열

카디널리티(Cardinality)는 열이 가질 수 있는 유일한 값의 수입니다. email처럼 모든 값이 다른 열은 카디널리티가 높아 인덱스 효과가 큽니다. 반면 grade처럼 VIP/PREMIUM/REGULAR 세 가지뿐인 열은 카디널리티가 낮아 인덱스 효과가 작습니다(어차피 전체 데이터의 1/3씩 가져와야 하므로 전체 스캔과 큰 차이 없음).

📝 핵심 요약

이번 강에서 배운 내용을 정리하겠습니다.

개념	핵심
인덱스 역할	B-트리 구조로 대량 데이터에서 조회 속도 향상
자동 생성	PRIMARY KEY, UNIQUE 제약에 자동 인덱스 생성
CREATE INDEX	CREATE INDEX idx_이름 ON 테이블(열)
복합 인덱스	열 순서 중요 — 앞 열부터 조건을 사용해야 효과
EXPLAIN QUERY PLAN	인덱스 사용 여부 확인 (SCAN vs SEARCH)
부작용	DML 느려짐, 저장 공간 추가 사용

인덱스는 성능 최적화의 첫 번째 도구입니다. 느린 쿼리를 만나면 EXPLAIN QUERY PLAN을 확인하고, 적절한 인덱스를 추가하는 것만으로 수십 배 성능 향상이 가능합니다. 다음 23강에서는 좋은 테이블 설계의 원칙인 데이터 모델링 기초를 배웁니다. ER 다이어그램 읽는 법, 정규화의 핵심 개념, 1:N·M:N 관계를 테이블로 표현하는 방법을 익힙니다.