DB 인덱스는 정렬이 아니다

— 많은 개발자가 처음에 착각하는 개념 정리

DB를 처음 다루다 보면 이런 질문을 한 번쯤 하게 된다.

“이 컬럼에 인덱스를 걸면
데이터가 그 기준으로 정렬돼서 저장되는 거 아닌가?”

결론부터 말하면 아니다.
이 글에서는 DB 인덱스가 무엇이고, 무엇이 아닌지를 아주 쉬운 예제로 설명해본다.

1. DB 테이블은 원래 정렬되어 있지 않다

먼저 가장 중요한 전제부터 짚고 가자.

DB 테이블은 ‘정렬된 배열’이 아니다.

예를 들어, 어떤 테이블에 아래와 같은 데이터가 있다고 해보자.

이름	점수
철수	80
영희	95
민수	70
지수	90

이 데이터는:

점수 순으로 정렬돼 있지 않고
이름 순으로도 정렬돼 있지 않다

DB는 데이터를 저장할 때 순서를 보장하지 않는다.
그래서 ORDER BY를 쓰지 않으면 조회 결과의 순서는 항상 불확실하다.

2. 인덱스는 “정렬된 복사본”이다

그럼 인덱스는 뭐냐?

인덱스는 테이블과 별도로 만들어지는
‘정렬된 보조 자료구조’다.

위 테이블에서 점수 컬럼에 인덱스를 만들면,
DB 내부에는 이런 구조가 하나 더 생긴다.

점수 인덱스:

→ 민수
→ 철수
→ 지수
→ 영희

중요한 점은:

이건 테이블이 아니라 인덱스
실제 데이터는 그대로 있고
인덱스는 “어디에 어떤 데이터가 있는지”만 가리킨다

👉 즉,

테이블은 여전히 정렬 안 됨
인덱스만 정렬돼 있음

3. 인덱스가 없을 때 정렬은 어떻게 될까?

아래처럼 “점수 높은 순으로 2명만 뽑고 싶다”고 해보자.

SELECT *
FROM 학생
ORDER BY 점수 DESC
LIMIT 2;

이때 인덱스가 없다면, DB는 다음과 같은 순서로 동작한다.

학생 테이블에 있는 모든 데이터를 읽는다
점수 기준으로 전체 데이터를 정렬한다
정렬된 결과에서 상위 2명만 반환한다

이 방식은 데이터가 적을 때는 큰 문제가 없다.
하지만 데이터가 많아질수록 비용이 급격히 증가한다.

테이블 전체 스캔
메모리 사용 증가
정렬 비용 증가

즉, 정렬이 느려진다.

인덱스가 있으면 뭐가 달라질까?

같은 요청이지만 인덱스가 있으면 DB의 동작 방식은 완전히 달라진다.

이번에는 점수 컬럼에 인덱스가 있다고 가정해보자.

DB는 다음과 같이 동작한다.

이미 정렬되어 있는 점수 인덱스를 확인한다
높은 점수부터 필요한 만큼만 읽는다
해당 데이터의 실제 행(row)만 가져온다

이 과정에서는:

테이블 전체를 읽지 않고
정렬 작업도 새로 하지 않는다

👉 이미 정렬된 구조를 그대로 활용한다

그래서 훨씬 빠르다.

두 방식의 핵심 차이

인덱스가 없을 때
→ 데이터를 모두 읽고 정렬한다
인덱스가 있을 때
→ 이미 정렬된 인덱스를 따라간다

이 차이가 성능 차이의 핵심이다.

인덱스의 정확한 역할

많이들 이렇게 오해한다.

“인덱스를 걸면 데이터가 정렬된다”

정확한 표현은 이거다.

“인덱스를 걸면
정렬을 빠르게 할 수 있는 길이 생긴다”

테이블의 저장 순서 ❌ 바뀌지 않는다
정렬 성능 ✅ 크게 개선된다

인덱스는 검색만 빠르게 하는 것이 아니다

인덱스는 단순히 검색(WHERE)만 빠르게 하는 기능이 아니다.

다음과 같은 작업에서도 핵심적인 역할을 한다.

정렬 (ORDER BY)
범위 조회 (>, <, BETWEEN)
개수 제한 (LIMIT)

즉, 정렬과 범위 조회가 인덱스의 핵심 역할이다.

언제 인덱스를 고려해야 할까?

다음과 같은 경우라면 인덱스를 고려해야 한다.

목록 화면이 있다
최신순 / 점수순 / 날짜순 정렬이 있다
상위 몇 개만 자주 가져온다 (LIMIT)

반대로,

데이터가 거의 없거나
정렬이나 필터링을 거의 하지 않는 경우라면

굳이 인덱스를 추가하지 않아도 된다.

한 문장으로 정리

인덱스는
데이터를 정렬해 주는 기능이 아니라
정렬을 빠르게 하기 위한 보조 구조다.

마무리

DB 인덱스를 처음 접할 때
“인덱스 = 정렬”로 오해하는 것은 아주 자연스러운 일이다.

중요한 건 이 한 가지다.

테이블은 정렬되지 않는다.
인덱스만 정렬된다.

이 개념을 이해했다면
DB 인덱스의 핵심은 이미 잡은 것이다.