[Database] 데이터베이스(DB) 인덱스(Index)

Database

[Database] 데이터베이스(DB) 인덱스(Index)

imnyoung 2025. 11. 24. 00:03

1. 데이터베이스(DB) 인덱스(Index)란?

인덱스(Index)는 DB 테이블에 대한 검색 속도를 높여주는 자료 구조이며, 인덱싱(Indexing)은 이러한 인덱스를 DB에 남기는 것이다.

우리가 국어사전에서 원하는 단어를 찾을 때 ㄱ, ㄴ, ㄷ 으로 정렬된 자음 목차를 활용하는 것과 같은 개념이다.

출처: https://velog.io/@bagt/DB-Index%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC

2. 인덱싱을 사용하는 이유

우리가 테이블을 생성하고 데이터가 쌓이면, 테이블의 레코드는 내부적으로 순서가 없이 뒤죽박죽으로 저장된다.

이 상황에서는 sql문 where절에서 작성한 특정 조건에 부합하는 데이터를 조회할 때에도 레코드의 처음부터 끝까지 모든 데이터를 읽어서 검색 조건과 맞는지 비교해야 한다. 이것을 Full Table Scan이라고 한다.

테이블에 데이터가 적다면 성능에 영향이 없겠지만, 만약 테이블에 수십만개의 데이터가 들어있는 경우라면 성능 저하가 생길 것이다.

이와 같이 DB를 다룰 때 대부분의 성능 저하는 조회 쿼리에서 나타나며, 특히 where절에서 많이 발생한다. 이때 가장 먼저 생각해볼 수 있는 대안이 인덱스가 될 수 있다.

[Example]

현재 이름, 성별, 이메일 등 백만 건 이상 데이터가 들어있는 member라는 테이블이 있다. 여기서 이메일이 tistory@tistory.com인 회원에 대한 조회(select)는 어떻게 이루어질까?
만약 데이터가 특정 기준 없이 저장된 상태라면, 전체 데이터에서 순차석으로 확인할 것이기 때문에 매우 느릴 것이다. 하지만 데이터가 이메일을 기준으로 정렬되어 있고, DB가 이 사실을 안다면, where절을 통해 이메일 검색을 빠르게 할 수 있다!

여기서 주의할 점은, email 컬럼에만 인덱스를 생성했다면 email 조건에만 직접적으로 도움이 된다.
1) email 컬럼에 인덱스가 있다면 SELECT * FROM member WHERE email = 'tistory@tistory.com'; → 인덱스를 사용
2) email에만 인덱스가 있고 name에는 인덱스가 없다면 SELECT * FROM member WHERE name = 'tistory'; → 인덱스를 사용하지 않고 Full Scan

3. 인덱스의 종류

인덱스의 종류에는 여러가지가 있으며, B-tree Index가 가장 대표적이다.
이 부분은 이후에 좀 더 공부 후 다뤄볼 예정!

4. 인덱스의 장단점

1) 인덱스의 장점

앞에서 말했듯이 테이블을 검색하는 속도와 성능이 향상된다.
또한 인덱스를 이용하면 데이터들이 이미 그 기준으로 정렬되어 있기 때문에 ORDER BY 문이나 MIN/MAX 같은 경우도 빠르게 수행할 수 있다.

2) 인덱스의 단점

1. 인덱스를 관리하기 위한 추가 작업 필요

인덱스의 가장 큰 문제점은 정렬된 상태를 계속 유지시켜줘야 한다는 점이다.
만약 인덱스가 적용된 컬럼에 삽입(INSERT), 삭제(DELETE), 수정(UPDATE) 작업을 수행하면 다음과 같은 추가 작업이 필요하다.

- INSERT : 새로운 데이터에 대한 인덱스를 추가
- DELETE : 삭제하는 데이터의 인덱스를 사용하지 않는다는 것을 알리는 작업 수행
- UPDATE : 기존의 인덱스를 사용하지 않음 처리, 갱신된 데이터에 대한 인덱스 추가

2. 추가 저장 공간 필요

인덱스는 하나의 테이블을 생성해 값을 저장해놓고 사용한다. 즉 다른 테이블에 의존적인 새로운 테이블이 하나 더 생성되는 것이므로 무분별한 인덱스 생성은 오히려 성능 저하를 초래할 수 있다.

3. 잘못 사용하는 경우 오히려 검색 성능 저하

검색 시에도 인덱스가 무조건 유용한 것은 아니다.

인덱스는 테이블의 전체 데이터 중 10~15% 이하의 데이터를 처리하는 경우에만 효율적이고, 그 이상의 데이터를 처리할 땐 인덱스를 사용하지 않는 것이 낫다.
예를 들어 나이나 성별과 같이 값의 range가 적은 컬럼인 경우, 인덱스를 읽고 나서 많은 데이터를 다시 조회해야 하기 때문에 비효율적이다.

5. 인덱스를 사용하면 좋은 경우

1. 규모가 큰 테이블
2. 삽입(INSERT), 삭제(DELETE), 수정(UPDATE) 작업이 자주 발생하지 않는 컬럼
3. WHERE나 ORDER BY, JOIN 등이 자주 사용되는 컬럼
4. 데이터의 중복도가 낮은 컬럼

예를 들어 "배달의 민족" 같은 서비스는 주로 사용자가 지역별 배달 음식점을 조회하고 검색하는 기능이 서비스의 주요 기능이므로 인덱스 기능을 잘 사용한다면 데이터베이스의 성능을 최적화시킬 수 있을 것이다.
반면에 "페이스북" 같은 소셜 미디어는 새로운 게시글들이 사용자들에 의해 끊임없이 생성되기 때문에 인덱스 기능을 사용하는 것이 오히려 성능 저하게 원인이 될 수도 있다.

따라서 서비스의 비즈니스 로직 혹은 테이블 사용 용도에 따라 인덱스 사용 여부를 신중하게 고민해봐야 한다.