백엔드/DB

DB 인덱스의 동작 원리와 성능 개선

코딩 화이팅 2025. 3. 25. 16:03

인덱스(Index)란?

  • 책의 목차와 같다.
    • 책을 읽을 때, 어떤 내용이 몇 쪽에 있는지 빠르게 찾고 싶을 때 맨 앞에 있는 목차를 보듯이, DB에서 인덱스도 같은 역할을 한다.
  • 데이터를 빠르게 찾을 수 있도록 도와주는 목차 역할
  • 만약 인덱스를 쓰지 않는다면 전체 앨범 100장에서 내가 나온 사진을 찾으려면 처음부터 100장을 전부 뒤져야 한다.
  • 인덱스를 쓰게 되면 DB가 미리 정리된 이름 목록을 가지고 있다.
    • 이 목록을 보고 내가 있는 위치를 바로 알게 되어 바로 해당 페이지로 넘어갈 수 있다.

왜 DB에서 Index를 사용해야 할까?

  • 위 예시서 SELECT 문을 활용해 USERS 테이블에 있는 AGE Column에 있는 25라는 값을 조회한다고 해보자
  • 그렇다면 SELECT 문은 모든 테이블에 있는 데이터를 모두 조회한 후 최종적으로 25가 포함된 모든 값들을 반환하는 로직으로 작동할 것이다.
  • 인간이 위 테이블을 직관적으로 봐서 결과를 찾아낼 때에는 25가 마지막으로 들어 있는 "위치"를 알고 아래 데이터들은 무시할 수 있다.
  • 하지만 데이터베이스 조회 구문은 25값의 마지막 위치가 어디인지 모르기 때문에 데이터 전체를 탐색함으로써 결과를 반환해준다.
  • 만약 데이터가 수십만 개가 들어 있을 때 조회 기능이 자주 실행되는 서비스가 있다면 계속해서 데이터베이스를 처음부터 끝까지 조회하면 값을 반환하기 때문에 트래픽에 따라 성능이 저하될 수 밖에 없다.
  • 데이터베이스에서도 이러한 문제점을 방지하고자 "index"를 활용해 자주 조회되는 Column에 대한 Index Table을 따로 만들어 SELECT문이 들어왔을 때 Index 테이블에 있는 값들로 결과 값을 조회해 온다.
  • 따라서 Index를 잘 사용한다면 "검색" 연산을 실행했을 때 성능을 드라마틱하게 올릴 수 있게 된다.

인덱스의 동작 방식

대부분의 DB는 B-Tree(이진 트리)라는 구조를 사용

           [50]
          /    \
      [30]      [70]
     /   \      /   \
   [20] [40]  [60] [80]
  • 나무처럼 생긴 구조
    • 작은 값은 왼쪽, 큰 값은 오른쪽에 놓고 가지를 타고 내려가면서 빠르게 찾아가는 방식
  • 위와 같은 숫자 인덱스가 생겼다고 가정했을 때, 40을 찾고 싶다면 50보다 작으니까 왼쪽으로 이동, 30보다 크니까 오른쪽으로 이동해서 찾을 수 있다.

인덱스는 언제 쓸까?

조건문(WHERE) 자주 씀? 인덱스 O
정렬 (ORDER BY) 자주 함? 인덱스 O
조회가 잦고 변경은 적음 인덱스 O
자주 수정되는 데이터 X 인덱스 과도하면 성능 저하

인덱스의 종류

단일 인덱스

  • 하나의 컬럼에 인덱스를 건 것
  • 예 : name만 인덱스

복합 인덱스(Composite Index)

CREATE INDEX idx_name_email ON users(name, email);
  • 여러 개 컬럼을 묶어서 인덱스를 만드는 것
  • 위 인덱스는 name만 조건에 있을 때는 쓸 수 있지만 email만 있을 때는 쓸 수 없다.
  • 복합 인덱스는 왼쪽부터 읽는 것만 가능하다

인덱스의 단점

  • 공간을 차지한다.
    • 책 목차도 너무 많으면 책보다 목차가 더 두꺼워진다.
    • 마찬가지로 인덱스도 디스크 공간을 사용한다.
  • INSERT / UPDATE / DELETE가 느려질 수 있다.
    • 누군가 새로운 사진을 앨범에 넣을 때마다 목차도 함께 업데이트해아 한다.
    • 즉, 데이터가 변경되면 인덱스도 같이 바꿔줘야 하니까 속도가 느려진다.