인덱스와 조회 성능: 데이터베이스가 원하는 데이터를 빠르게 찾는 방법

조회가 느려질 때, 데이터가 아니라 “찾는 방식”이 문제인 경우가 많다

게시글 목록을 열면 로딩이 길어지고, 주문 내역 검색은 한참 돌아가며, 관리자 페이지는 클릭할수록 답답해지는 경우가 있다.

데이터가 많아져서 그렇다고 생각하지만, 실제로는 “어떻게 찾느냐”에 따라 속도가 크게 갈린다.

인덱스는 데이터를 저장하는 방식이 아니라, 조건에 맞는 행을 빨리 찾기 위한 길 안내판에 가깝다.

• 인덱스가 없을 때 어떤 일이 벌어지는가
• 인덱스가 빠른 이유와 내부 동작 방식
• 인덱스를 잘못 잡았을 때 생기는 부작용
• 선택 기준 비교표와 YES/NO 체크리스트
• 느린 검색 화면을 예시로 확인·해결 절차 정리

인덱스는 “정렬된 보조 목록”으로 조회 범위를 줄이는 장치다

세션 스토리지: 탭을 닫으면 사라지는 임시 보관함

정의: 인덱스는 특정 컬럼 값을 기준으로, 해당 값이 있는 행의 위치를 빠르게 찾을 수 있도록 만든 별도의 자료구조다.

핵심 특징: 전체 테이블을 처음부터 끝까지 훑지 않고, 조건에 맞는 구간으로 바로 점프하도록 도와준다.

• 수명: 테이블 데이터와 별개로 유지되며, 인덱스를 삭제하면 조회 경로만 바뀌고 데이터는 남는다.
• 범위: 인덱스를 건 컬럼과 조건이 맞아야 효과가 난다. 다른 컬럼 조건에는 도움이 제한적이다.
• 원리: 보통 정렬된 트리 구조(B-Tree 계열)로 저장되어, 범위를 반씩 줄이며 후보를 좁힌다.
• 문자열 저장: 문자열도 인덱싱 가능하지만, 긴 문자열이나 앞부분이 제각각인 값은 효율이 떨어질 수 있다.

주의점: 인덱스는 공짜가 아니다. 저장 공간을 추가로 쓰고, 데이터 변경 시 인덱스도 같이 갱신해야 한다.

주의점: 잘못된 인덱스는 조회 성능을 올리지 못하면서 쓰기 성능만 떨어뜨릴 수 있다.

로컬 스토리지: 브라우저에 남아 있는 지속 보관함

정의: “어떤 조건으로 자주 찾는가”에 맞춰 인덱스 키를 설계하면, DB는 필요한 행을 좁은 범위에서 고르게 된다.

핵심 특징: 조건과 정렬이 인덱스와 맞으면 디스크 접근이 줄고, 필요한 행만 읽어 오기 쉬워진다.

• 수명: 조회가 빨라지는 대신, 삽입/수정/삭제가 일어날 때마다 인덱스 갱신 비용이 함께 발생한다.
• 범위: 같은 테이블이라도 “자주 쓰는 화면”과 “자주 쓰는 조건”이 다르면 다른 인덱스가 필요하다.
• origin: 애플리케이션 관점에서는 서비스(업무)별로 조회 패턴이 다르다. 인덱스는 그 패턴에 맞춰야 한다.
• 삭제/정리 필요성: 인덱스가 늘어나면 운영 비용이 쌓인다. 사용되지 않는 인덱스는 정리 대상이 된다.

주의점: 인덱스를 많이 걸면 무조건 빨라질 것 같지만, DB는 실행 계획을 보고 “인덱스를 타는 것이 이득인지”를 매번 판단한다.

주의점: 조건이 인덱스와 어긋나면, 인덱스가 있어도 전체 스캔에 가까운 동작을 할 수 있다.

 

인덱스가 없는 조회와 인덱스를 탄 조회의 차이

 

어떤 인덱스가 도움이 되는지 판단하는 기준은 “화면의 질문”에서 시작한다

인덱스 설계는 추상적인 규칙보다, 사용자가 화면에서 던지는 질문을 그대로 받아 적는 것이 더 정확하다.

예를 들어 “최근 7일 주문 중 결제 완료만 보기”, “특정 고객의 주문만 보기”, “상품명으로 검색”은 서로 다른 인덱스를 요구한다.

 

인덱스 설계 판단 플로우

 

항목	인덱스가 잘 먹는 경우	효과가 약한 경우
조건 형태	정확 일치(=), 범위(>, <, BETWEEN), 앞부분 일치(prefix)	컬럼에 함수 적용, 앞에 와일드카드(예: %키워드)
정렬	ORDER BY가 인덱스 순서와 일치	정렬 컬럼이 달라 추가 정렬 발생
데이터 분포	값 종류가 많아(선택도가 높아) 잘 걸러짐	값이 거의 같아(선택도가 낮아) 걸러지지 않음
운영 비용	조회가 많고 변경이 상대적으로 적음	삽입/수정/삭제가 매우 잦음

표 제목: 인덱스 적용 여부를 가르는 핵심 비교

어떤 상황이면 무엇을 하는가: YES/NO 체크리스트

• 질문: 특정 목록/검색 화면이 반복적으로 느린가. YES: 해당 화면의 WHERE/ORDER BY를 먼저 적어 보고 인덱스 후보를 뽑는다. NO: 먼저 서버 자원이나 네트워크 등 다른 병목을 의심한다.
• 질문: WHERE 조건 컬럼이 “자주 바뀌지 않고” 값 종류가 다양한가. YES: 단일 인덱스 후보가 된다. NO: 인덱스보다 캐시, 요약, 쿼리 수정이 먼저일 수 있다.
• 질문: WHERE + ORDER BY가 같이 자주 쓰이는가. YES: 복합 인덱스를 고려한다. NO: 단일 인덱스 또는 쿼리 구조 개선으로 충분할 수 있다.
• 질문: 인덱스를 추가해도 쓰기 성능 하락이 감당 가능한가. YES: 운영 지표를 보며 적용한다. NO: 필요한 화면에만 제한적으로 적용하거나 다른 방법을 찾는다.
• 질문: 실행 계획(EXPLAIN)에서 인덱스를 타지 않고 전체 스캔을 하는가. YES: 조건 형태를 바꾸거나 인덱스 구성을 다시 본다. NO: 인덱스가 이미 도움이 되고 있으니 다른 병목을 확인한다.

실전 예시: “최근 주문 목록”이 느릴 때 인덱스로 해결하는 흐름

문제: 관리자 페이지에서 “최근 30일 주문 목록”을 열면 로딩이 길어지고, 페이지를 넘길수록 더 느려진다.

왜 발생: 주문 테이블이 커졌는데, 조회가 날짜 조건과 상태 조건을 걸고 정렬까지 하면서도 인덱스가 없어 전체를 훑고 정렬하는 비용이 커진다.

어떤 저장소가 적합: 이 상황에서 필요한 것은 저장소 변경이 아니라 “조회 경로 개선”이다. 날짜(created_at)와 상태(status)처럼 자주 쓰는 필터와 정렬에 맞춰 인덱스를 설계하는 편이 맞다.

잘못 쓰면 어떤 문제: status 단독 인덱스처럼 값 종류가 적은 컬럼에만 인덱스를 걸면, 걸러지는 폭이 작아 기대만큼 빨라지지 않는다. 복합 인덱스를 만들 때 컬럼 순서를 잘못 잡으면 ORDER BY 최적화가 풀려 추가 정렬이 발생할 수 있다.

확인/해결: 화면이 사용하는 쿼리를 고정하고, 실행 계획으로 “어떤 단계에서 비용이 큰지”를 확인한 뒤 인덱스를 추가해야 한다.

브라우저에서 확인하는 방법: 실행 계획을 보고 인덱스가 쓰이는지 점검하는 순서

1. DB 콘솔(클라우드 DB 관리 화면 또는 SQL 툴)을 브라우저에서 연다.
2. 느린 화면에서 실제로 실행되는 SQL을 확보한다(서버 로그, APM, 애플리케이션 로그 등).
3. SQL 앞에 EXPLAIN(또는 DB가 제공하는 실행 계획 명령)을 붙여 실행한다.
4. 실행 계획에서 전체 스캔(Full Scan)에 가까운 동작이 있는지, 정렬 단계가 큰지 확인한다.
5. WHERE에 쓰이는 컬럼과 ORDER BY 컬럼을 기준으로 인덱스 후보를 정리한다.
6. 인덱스 추가 후 동일 SQL로 EXPLAIN을 다시 실행해, 인덱스를 타는지와 예상 비용이 줄었는지 비교한다.
7. 조회 속도를 다시 측정하고, 쓰기 성능(삽입/수정) 저하가 없는지 운영 지표로 확인한다.

결론

인덱스는 조건에 맞는 데이터를 빨리 찾기 위한 “정렬된 길 안내”다.

조회 패턴(WHERE/ORDER BY)과 데이터 분포에 맞을 때 효과가 크게 난다.

실행 계획으로 확인하고, 필요한 화면에만 제한적으로 적용하는 편이 운영이 안정적이다.

• 다음에 읽으면 좋은 연계 주제: 실행 계획(EXPLAIN)에서 비용이 큰 구간을 찾는 법
• 다음에 읽으면 좋은 연계 주제: 복합 인덱스 컬럼 순서를 정하는 실무 기준

FAQ

인덱스를 만들면 모든 조회가 빨라지는가

조건이 인덱스와 맞아야 빨라진다. 조건 컬럼이 다르거나, 컬럼에 함수를 적용해 인덱스를 못 타는 형태면 효과가 제한적이다.

인덱스가 많으면 왜 문제가 되는가

인덱스는 저장 공간을 추가로 쓰고, 삽입/수정/삭제 때마다 인덱스를 갱신해야 한다. 조회만 보고 무작정 늘리면 쓰기 성능과 운영 비용이 함께 커진다.

복합 인덱스는 어떤 기준으로 컬럼 순서를 정하는가

자주 쓰는 WHERE 조건과 정렬 조건을 기준으로, 먼저 많이 걸러지는 컬럼을 앞에 두는 방식이 흔하다. 다만 실제 쿼리와 실행 계획을 보고 조정하는 과정이 필요하다.