Index

인덱스란

데이터베이스에서 데이터를 조회하려면, 기본적으로 테이블 전체를 훑는 전체 검색(Full Scan)을 수행해야 합니다.

이는 시간이 오래 걸릴 수 있습니다. 그래서 등장한 것이 바로 인덱스입니다.

 

인덱스는 값(Key)과 데이터 주소(Value)의 쌍 (Key-Value Pair)로 구성되어 있으며, 원하는 데이터를 더 빠르게 찾을 수 있도록 돕는 구조입니다. 즉, 인덱스는 정렬된 찾아보기로 생각하면 됩니다.

 

인덱스 핵심 구조

DB 인덱스는 보통 항상 정렬된 상태를 유지합니다.

이를 위해 SortedList와 같은 자료구조가 활용되며, 이는 값을 삽입할 때마다 정렬을 유지하는 구조입니다.

이 구조 덕분에 SELECT는 빠르지만, INSERT/UPDATE/DELETE는 느릴 수 있습니다.

 

인덱스의 장점과 단점

항목	설명
장점	SELECT 속도 향상(찾아보기를 이용해 빠르게 탐색)
단점	INSERT/UPDATE/DELETE 속도 저하(정렬 유지 비용)

 

인덱스는 조회 성능을 높이는 대신 쓰기 성능을 희생하는 구조입니다.

인덱스가 많아질수록 SELECT는 빨라지지만, 그만큼 INSERT/UPDATE의 성능은 저하되며, 디스크 공간도 더 많이 사용됩니다.

 

인덱스 저장 알고리즘

DB 인덱스는 내부적으로 다양한 알고리즘을 사용합니다. 대표적으로는 B-Tree 인덱스와 Hash 인덱스가 있습다.

 

B-Tree 인덱스

가장 일반적이고 널리 사용되는 인덱스이고, 컬럼 값을 그대로 정렬해 검색에 사용합니다.

MySQL에서 InnoDB의 기본 인덱스 방식입니다.

 

Hash 인덱스

컬럼 값을 해시 함수로 변환해 저장하고, 정확한 일치(equal) 검색에는 매우 빠르지만, 범위 검색, 정렬에는 사용이 불가능합니다.

 

인덱스 키의 종류

키 종류	설명
Primary Key(기본 키)	중복이 없는 고유 식별자
Secondary Key(보조 키)	다른 컬럼에 인덱스를 걸 때 사용
Unique Index	고유한 값을 보장
Non-Unique Index	중복 허용

 

프라이머리 키는 기본적으로 인덱스가 생성되며, 그 외의 인덱스는 보통 세컨더리 인덱스로 분류됩니다.

 

인덱스 생성 시 주의점

SELECT 쿼리의 WHERE 조건절에서 자주 사용되는 컬럼에 인덱스를 걸고, INSERT/UPDATE가 잦은 칼럼에는 과도한 인덱스 생성을 금지해야 합니다. 인덱스는 디스크 공간을 추가로 사용하여, 너무 많으면 오히려 성능을 해칠 수 있습니다.

 

WHERE 조건절에서 자주 사용되는 컬럼에 인덱스를 걸어야 하는 이유

SELECT * FROM users WHERE age = 30

 

이 쿼리는 users 테이블 전체에서 age가 30인 데이터만 골라내야 합니다.

인덱스가 없는 경우, DB는 age = 30을 만족하는 데이터를 찾기 위해 테이블 전체를 읽는 Full Table Scan을 해야 합니다.

이는 레코드가 수십만, 수백만 개일 경우 매우 비효율적입니다.

 

만약 age 컬럼에 인덱스가 있다면, DB는 인덱스만 훑어서 age = 30이 있는 레코드의 주소를 바로 찾아냅니다.

그리고 해당 주소로 가서 실제 데이터를 읽습니다. 즉, 불필요한 레코드를 읽지 않아도 됩니다.

 

 

인덱스의 트레이드 오프

인덱스는 SELECT를 빠르게 하기 위해 등장했지만, 쓰기 속도와 저장 공간이라는 비용을 동반합니다.

"SELECT는 빠르게, INSERT는 느리게" 이것이 인덱스의 본질입니다.

인덱스를 언제, 어떻게, 어떤 컬럼에 적용할지 신중히 고려하는 것이 데이터베이스 성능 최적화의 핵심 포인트 입니다.

 

 

참조

• Real MySQL 8.0(1권)