추가적인 쓰기 작업과 저장 공간을 활용하여 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조
Index는 책의 색인과 같다. 데이터베이스에서도 테이블의 모든 데이터를 검색하면 시간이 오래 걸리기 때문에
데이터와 데이터의 위치를 포함한 자료구를 생성하여 빠르게 조회할 수 있도록 돕고 있다.

인덱스를 활용하면 데이터를 조회하는 SELECT 외에도 UPDATE나 DELETE의 성능이 함께 향상된다.
인덱스 관리
DBMS는 Index를 항상 최신의 정렬된 상태로 유지해야 원하는 값을 빠르게 탐색할 수 있다.
인덱스가 적용된 컬럼에 Insert, Update, Delete가 수행된다면 각각 다음과 같은 연산을 추가적으로 해주어야 한다.
- Insert : 새로운 데이터에 대한 인덱스를 추가함
- Delete : 삭제하는 데이터의 인덱스를 사용하지 않는다는 작업을 진행함
- Update : 기존의 인덱스를 사용하지 않음 처리하고, 갱신된 데이터에 대해 인덱스를 추가함
인덱스를 사용하는 것 만큼이나 생성된 인덱스를 관리해주는 것도 중요하다.
사용되지 않는 인덱스는 바로 제거하기.
인덱스의 장단점
- 장점
- 테이블을 조회하는 속도와 그에 따른 성능을 향상시킬 수 있음
- 전반적인 시스템의 부하를 줄일 수 있음
- 시간복잡도 : O(N) --> O(logN) B-tree based index
- 단점
- 인덱스를 관리하기 위해 DB의 약 10%에 해당하는 저장공간이 필요함
- 인덱스를 관리하기 위해 추가 작업이 필요함
- 인덱스를 잘못 사용할 경우 오히려 성능이 저하되는 역효과 발생 가능
인덱스를 사용하면 좋은 경우
- 규모가 작지 않은 테이블
- Insert, Update, Delete가 자주 발생하지 않는 컬럼
- Join이나 where, order by에 자주 사용되는 컬럼
- 데이터의 중복도가 낮은 컬럼
인덱스 생성 쿼리
-- 테이블 생성 시
create table user (
id int primary key,
name varchar(255) not null,
user_id int not null,
back_number int not null,
index user_name_idx (name),
unique index user_id_back_number_idx (user_id, back_number)
);
-- index 생성
-- single column
create index user_name_idx on user (name);
-- multi column
create unique index user_id_back_number_idx on player (user_id, back_number);
인덱스의 자료구조
인덱스를 구현하기 위해서는 다양한 자료구조를 사용할 수 있는데, 가장 대표적인 해시 테이블과 B+ Tree가 있다.
해시 테이블(Hash Table)
해시 테이블은 (Key, Value)로 데이터를 저장하는 자료구조 중 하나로 빠른 데이터 검색이 필요할 때 유용하다.
시간복잡도는 O(1)이며 매우 빠른 검색을 지원한다. 하지만 DB 인덱스에서 해시 테이블이 사용되는 경우는 제한적이다.

그 이유는 해시가 등호(=) 연산에만 특화되었기 때문이다. 해시 함수는 값이 1이라도 달라지면 완전히 다른 해시 값을 생성하는데
이러한 특성에 의해 부등호 연산(>,<)이 자주 사용되는 데이터베이스 검색을 위해서는 해시 테이블이 적합하지 않다.
B+ Tree
DB의 인덱스를 위해 자식 노드가 2개 이상인 B- Tree를 개선시킨 자료구조이다.
B+ Tree는 모든 노드에 데이터를 저장했던 B Tree와 다른 특성을 가지고 있다.
- 리프노드(데이터노드)만 인덱스와 함께 데이터를 가지고 있고, 나머지 노드(인덱스 노드)들은 데이터를 위한 인덱스(key)만을 갖는다.
- 리프노드들은 LinkedList로 연결되어 있다.
- 데이터 노드 크기는 인덱스 노드의 크기와 같지 않아도 된다.
데이터베이스의 인덱스 컬럼은 부등호를 이용한 순차 검색 연산이 자주 발생될 수 있다.
이러한 이유로 B Tree의 리프노드들은 LinkedList로 연결하여 순차검색을 용이하게 하는 등 B Tree를 인덱스에 맞게 최적화하였다.
(Best Case에 대해 리프노드까지 가지 않아도 탐색할 수 있는 B Tree에 비해 무조건 리프노드까지 가야한다는 장점있음)
이러한 이유로 비록 B+ Tree는 O(𝑙𝑜𝑔2𝑛)의 시간 복잡도를 갖지만 해시 테이블보다 인덱싱에 더욱 적합한 자료구조가 되었다.

InnoDB에서의 B+ Tree는 일반적인 구조보다 복잡하게 구현 되었다. InnoDB에서는 같은 레벨의 노드들끼리는 LinkedList가 아닌 Double LinkedList로 연결되었으며, 자식 노드들은 Single LinkedList로 연결되어 있다.
'Database' 카테고리의 다른 글
| MySQL 엔진 아키텍처 이해하기 (0) | 2025.10.09 |
|---|---|
| MySQL, PostgreSQL의 날짜와 시간 타입이 만든 혼란 (1) | 2025.04.23 |
| [ Database ] 정규화, 비정규화, 역정규화 (0) | 2024.01.08 |
| [데이터베이스] RDBMS, NoSQL (2) | 2023.12.16 |
| [데이터베이스] Join (0) | 2023.11.29 |