조회 대상 행이 적을 때도 Using filesort 제거를 고려해야 하나요?

작성한 질문수 5

0

안녕하세요. 슝스스님

1. 조회 및 정렬 대상이 5~8행 정도로 적다면 메모리 상에서 마이크로초 단위로 즉시 정렬되므로 `Using filesort`를 신경 쓰지 않으셔도 됩니다.

2. 이를 지우려고 불필요한 복합 인덱스를 추가하면 오히려 CUD(생성,수정,삭제) 쓰기 성능이 저하되는 부작용이 커집니다.

3. 실무에서는 정렬 대상이 수천~수십만 건 이상으로 폭증해 디스크 정렬이 발생하거나, 실제 쿼리 응답 속도가 느려질 때를 기준으로 튜닝하시면 됩니다.

감사합니다.

0

안녕하세요, 인프런 AI 인턴입니다. 슝스스님께서 질문하신 Using filesort와 성능 판단 기준에 참고할 만한 기존 답변을 안내드립니다.

조회 대상이 이미 5~8행 정도로 충분히 줄어든 상태라면, Using filesort가 발생하더라도 정렬 비용은 대체로 매우 작습니다. Using filesort는 반드시 디스크를 사용한다는 의미가 아니라, 인덱스 순서가 아닌 별도의 정렬 작업이 수행된다는 의미이므로 실제 실행 시간과 데이터 규모를 함께 확인하는 것이 중요합니다.

반대로 정렬 대상 행이 많거나, 대량 요청이 반복되는 쿼리라면 ORDER BY 조건에 맞는 인덱스를 구성해 filesort를 줄이는 것을 고려할 수 있습니다. 최종 판단은 EXPLAIN 또는 EXPLAIN ANALYZE를 통해 실제 정렬 대상 행 수, 실행 시간, 읽은 행 수, CPU 및 메모리 사용량 등을 측정하는 방식이 적절합니다.

관련 게시글을 참고해 주세요.

• limit, offset 에서 인덱스 동작
  ORDER BY 컬럼에 인덱스가 있을 때 filesort를 피할 수 있는 방식과, 인덱스가 없거나 정렬 대상이 많을 때의 비용을 설명하고 있습니다.
  
• 실무에서 sql 쿼리의 성능 개선
  성능 개선 여부를 판단할 때 실행 시간뿐 아니라 CPU, 메모리 사용량 등을 함께 확인해야 하며, “유의미한 개선”의 기준은 실제 서비스 상황에 따라 달라진다는 내용을 참고할 수 있습니다.
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.