기획·개발·운영데이터·구조 · 약 5분

APP DEVELOPMENT TERM

데이터베이스 인덱스

조회 조건에 맞춰 기록을 찾는 보조 구조

데이터베이스 인덱스는 특정 조건의 기록을 찾을 때 전체 데이터를 살펴보는 부담을 줄이도록, 값과 해당 기록을 찾을 정보를 따로 관리하는 보조 구조입니다.

DB 인덱스데이터베이스 색인Database Index

30초 이해

기록을 저장하는 일과 필요한 기록을 찾는 일은 다릅니다

관리자가 ‘10월 1일부터 7일까지, 완료된 업무’를 찾는다고 생각해보세요. 기록이 쌓일수록 어떤 조건으로 찾을지에 맞는 구조가 중요해집니다.

인덱스는 책 뒤의 찾아보기와 비슷합니다. 본문을 처음부터 읽는 대신 관련 항목으로 이동하듯, 조건에 맞는 기록을 찾는 경로를 제공합니다. 원본 기록을 대신하는 목록은 아닙니다.

DATABASE INDEX

조건에 맞는 범위를 찾고,
원본 기록으로 연결합니다

업무 목록에서 상태가 ‘완료’이고 업무일이 10/1~10/7인 기록을 찾는 흐름입니다.

  1. 01조회 조건

    어떤 기록을 찾을까요?

    상태와 날짜 조건을 함께 지정합니다.

    상태
    완료
    업무일
    10/1 ~ 10/7

    화면에서 자주 쓰는 조회 조건은
    인덱스를 정할 때 함께 살펴봅니다.

  2. 02인덱스

    찾기 위한 별도 구조

    상태 → 업무일 순서의 인덱스를 사용하는 경우입니다.

    ‘완료’ 구간의 일부

    상태업무일업무번호
    완료10/1101
    완료10/3103
    완료10/7104
    완료10/8105

    강조한 행이 이번 조건에 맞는 범위입니다. 찾기 구조는 원본과 별도로 관리합니다.

  3. 03원본 기록

    해당 기록의 값을 읽기

    업무명처럼 인덱스에 없는 값이 필요하면 원본 기록에서 읽습니다.

    업무 목록의 일부

    업무번호업무일상태
    10410/7완료
    10110/1완료
    10510/8완료
    10310/3완료
    10210/2진행

    이번 조건 밖의 기록도 보관됩니다. 원본 전체를 이 순서로 다시 정렬하는 것은 아닙니다.

조회 흐름을 단순화한 개념도입니다. 연결은 업무번호로 표현했습니다. 실제 인덱스 구조와 조회 방법은 데이터베이스·조회 조건에 따라 달라집니다.

언제 사용하는 개념인가요?

01

자주 쓰는 목록을 설계할 때

관리자가 반복해서 선택하는 날짜·상태 조건을 확인합니다.

02

데이터가 쌓이며 조회가 느려질 때

문제가 되는 조회와 실제로 읽는 데이터 범위를 살펴봅니다.

03

조회 조건이 달라질 때

새 필터·정렬이 기존 인덱스에 맞는지 다시 확인합니다.

왜 중요한가요?

  • 찾는 조건과 구조를 맞춥니다

    같은 표도 어떤 값으로 찾는지에 따라 필요한 인덱스가 다릅니다.

  • 조회와 저장의 부담을 함께 봅니다

    기록을 추가·삭제하거나 관련 값을 바꾸면 인덱스도 관리해야 하며 저장 공간도 사용합니다.

  • 실제 효과를 확인합니다

    인덱스를 만든 뒤에도 실행계획과 측정으로 도움이 되는지 검토해야 합니다.

업무 기록으로 비교하기

같은 업무 기록에서 완료 건을 찾는다면

두 방식 모두 ‘업무일 10/1~10/7, 상태 완료’를 조회합니다. 다른 조건의 기록이 결과에 섞이지 않아야 합니다.

이 조회에 쓸 인덱스가 없을 때

  • 표의 기록을 차례로 읽으며 날짜와 상태를 확인합니다.
  • 조건에 맞는 기록만 결과로 남깁니다.

맞는 인덱스를 활용할 때

  • 인덱스에서 조건에 맞는 범위를 좁힙니다.
  • 해당 기록을 읽어 같은 결과를 반환합니다.

표가 작거나 많은 기록을 가져오는 조회라면 전체를 차례로 읽는 편이 유리할 수 있습니다. 인덱스가 있어도 항상 사용되는 것은 아닙니다.

자주 묻는 질문

“인덱스는 많이 만들수록 좋나요?”

자주 쓰지 않는 인덱스도 공간과 관리 부담이 듭니다. 필요한 조회를 기준으로 추가하고, 저장·변경 작업에 미치는 영향도 확인합니다.

“날짜와 상태를 모두 넣으면 순서는 상관없나요?”

여러 열을 묶은 복합 인덱스는 순서도 중요합니다. B-tree 방식에서는 ‘상태를 먼저 고정하고 날짜 범위를 찾는’ 구조를 이 조회의 후보로 검토할 수 있습니다. 날짜만 찾는 조회 등 다른 사용 조건도 함께 비교해야 합니다.

“인덱스가 있으면 빠르게 조회되는 것이 보장되나요?”

조회 조건, 데이터량과 값의 분포에 따라 달라집니다. 실행계획은 데이터베이스가 어떤 경로로 읽으려 하는지 보여줍니다. 이를 확인하고 실제 조회도 측정해 개선 여부를 판단합니다.

우리 서비스에 적용할 때 확인하세요

  1. 1어떤 화면에서 어떤 날짜·상태 조건으로 가장 자주 찾나요?
  2. 2한 번에 가져올 기록의 범위와 정렬 순서는 무엇인가요?
  3. 3인덱스 추가 전후의 실행계획·조회 결과·저장 부담을 함께 확인했나요?

공식 참고

서비스 기준은 공식 문서에서 다시 확인하세요

다음 자료

이해한 내용을 바로 적용해보세요

이 글은 데이터베이스 안에서 기록을 찾는 구조를 다룹니다. 구글·네이버가 웹페이지를 검색 목록에 등록하는 ‘색인’과는 다릅니다. 저장 구조와 변경, 화면의 탐색 기준은 아래 용어에서 이어 볼 수 있습니다.

우리 서비스에서 자주 찾는 조건을 적어보세요

주요 목록 하나를 골라 조회 조건·정렬·결과 범위를 정리하면 개발팀과 인덱스 검토 기준을 구체적으로 맞출 수 있습니다.