SQL ORDER BY 대신 인덱스 활용하기

 

 

select /*+ index_desc(테이블명 인덱스명) */
*
form 테이블명
where 컬럼명 > 0;

 

쿼리 성능을 튜닝하다 보면 ORDER BY가 은근히 발목을 잡는 경우가 많다.

처음에는 잘 돌아가던 쿼리도 데이터가 쌓이기 시작하면 갑자기 느려지는 경험을 한 번쯤 해봤을 것이다.

왜 이런 일이 생길까 생각해보면 답은 단순하다. ORDER BY는 결국 “정렬” 작업이기 때문이다.

데이터가 많아질수록 정렬 비용이 커지고, 이게 그대로 성능 저하로 이어진다.

 

 

---

ORDER BY가 느린 이유

 

예를 들어 이런 쿼리가 있다고 가정해본다.

SELECT *
FROM posts
ORDER BY created_at DESC;

데이터가 적을 때는 문제가 없지만, 수십만 건 이상 쌓이면 이야기가 달라진다.

DB는 이 데이터를 전부 읽은 뒤 정렬해야 하기 때문에 추가적인 작업이 발생한다.

특히 인덱스를 제대로 활용하지 못하는 경우라면, 디스크 I/O + 정렬 비용까지 더해져서 체감 성능이 확 떨어진다.

---

해결 방법: 인덱스를 이용해서 “이미 정렬된 상태”로 만들기

핵심 아이디어는 간단하다.

👉 정렬을 하지 말고, 애초에 정렬된 상태로 읽어오면 된다.

인덱스는 기본적으로 정렬된 구조를 가지기 때문에 특정 컬럼에 인덱스가 있다면 DB는 그 인덱스를 따라 순서대로 데이터를 읽을 수 있다.

예를 들어:

CREATE INDEX idx_posts_created_at ON posts(created_at DESC);

이렇게 인덱스를 만들어두면, 아까 쿼리는 실제로 정렬을 하지 않고도 빠르게 결과를 반환할 수 있다.

즉, ORDER BY를 쓰긴 했지만 내부적으로는 “정렬 생략”이 되는 셈이다.

 

 

---

중요한 포인트 몇 가지

 

1. 인덱스 방향도 중요

ASC, DESC 방향에 따라 인덱스 활용 여부가 달라질 수 있다.

DBMS에 따라 다르지만 방향까지 맞춰주는 게 안전하다.

 

2. 복합 인덱스는 순서가 생명

예를 들어 (user_id, created_at) 인덱스가 있다면:

WHERE user_id = 1
ORDER BY created_at DESC;

이건 잘 타지만,

ORDER BY created_at DESC;

이건 인덱스를 제대로 못 탈 수도 있다. 컬럼 순서가 중요하다.

 

3. 인덱스 남용은 오히려 독 ☠️

인덱스가 많아질수록 INSERT/UPDATE 성능은 떨어진다.

무조건 많이 만드는 게 아니라 “자주 조회되는 패턴” 기준으로 설계하는 게 중요하다.

 

---

결국 중요한 건 ORDER BY를 없애는 게 아니라 정렬이 필요 없는 구조를 만드는 것이다.

인덱스를 잘 설계하면 쿼리는 그대로 두고도 성능을 크게 개선할 수 있다.

쿼리 튜닝은 문법 싸움이 아니라 실행 방식 싸움이라는 점을 기억해두면 좋다.