인덱스를 추가하기 전에 먼저 확인했던 조회 패턴

쿼리가 느려지기 시작하면 가장 먼저 떠오르는 해결책은 보통 인덱스입니다.
저도 한동안은 그랬습니다. 실행 시간이 길면 "이 컬럼에 인덱스 하나 걸면 되겠지"라고 생각했습니다.

그런데 실무에서는 그렇게 단순하게 풀리지 않는 경우가 많았습니다.
인덱스를 추가했는데도 기대만큼 빨라지지 않거나, 반대로 쓰기 성능만 나빠지는 경우도 있었습니다.

결국 느린 쿼리를 볼 때는 인덱스 자체보다, 어떤 조회 패턴으로 데이터가 읽히는지를 먼저 보는 쪽으로 습관이 바뀌었습니다.

처음엔 where 절 컬럼만 보고 인덱스를 생각했다

예전에는 이런 식으로 봤습니다.

select *
from orders
where user_id = ?
order by created_at desc
limit 20;

그러면 바로 user_id에 인덱스를 추가하려고 했습니다.
물론 틀린 접근은 아니지만, 실제로는 그것만으로 부족한 경우가 많았습니다.

이 쿼리는 단순히 where user_id = ?만 보는 게 아니라,

를 같이 봐야 했습니다.

실무에서는 동일한 테이블이라도 조회 방식이 화면마다 달랐습니다.

이걸 하나의 인덱스로 다 해결하려 하면 금방 복잡해집니다.
그래서 지금은 쿼리 하나만 보지 않고, 어떤 화면에서 어떤 조건 조합이 반복되는지를 먼저 묶어 봅니다.

이 단계 없이 인덱스를 넣으면 "느린 쿼리 하나"는 잠깐 빨라져도, 전체 패턴과는 맞지 않을 때가 많았습니다.

조회가 느린데 필터 컬럼만 보고 인덱스를 넣으면, 정렬 단계에서 다시 비용이 커지는 경우가 있었습니다.

예를 들어 사용자별 최근 주문 목록이라면,

를 같이 보게 됩니다.

이 경우 실무에서는 단일 인덱스보다 복합 인덱스를 먼저 검토하는 편이 낫습니다.
필터와 정렬이 같이 자주 쓰이는 패턴이라면, 조회 체감 차이가 꽤 컸습니다.

인덱스를 추가해도 여전히 느릴 때는, 결국 읽어오는 데이터 양이 너무 많았던 경우가 많았습니다.

실무에서는 인덱스를 넣기 전에 쿼리 자체를 더 가볍게 만들 수 있는 경우가 꽤 있었습니다.
오히려 이쪽이 더 큰 효과를 내는 경우도 많았습니다.

느린 쿼리를 볼 때 제일 후회했던 순간은, 실행 계획도 안 보고 인덱스부터 넣었던 때였습니다.

실행 계획을 보면 최소한 아래는 확인할 수 있습니다.

실무에서는 "인덱스가 있다"와 "그 인덱스를 잘 탄다"가 전혀 다른 이야기였습니다.

급하게 대응하다 보면 비슷한 인덱스가 여러 개 생기기도 합니다.

이런 식으로 추가하다 보면, 실제로는 하나로 충분한데 관리 대상만 늘어나는 경우가 있었습니다.
쓰기 비용과 저장 비용도 무시할 수 없어서, 인덱스는 늘릴수록 좋다는 생각은 위험했습니다.

인덱스를 추가하기 전에는 보통 아래 순서로 봅니다.

이 순서를 거치고 나면 "무조건 인덱스 추가"보다 훨씬 덜 흔들리게 됩니다.

실무에서 인덱스는 느린 쿼리를 고치는 도구이기도 했지만, 그보다 조회 패턴을 이해했는지 확인하는 지표에 가까웠습니다.

결국 쿼리를 빠르게 만드는 건 인덱스 하나를 추가하는 행위보다,
어떤 화면이 어떤 방식으로 데이터를 읽는지 먼저 이해하는 데서 시작된다고 느꼈습니다.