인프런 커뮤니티 질문&답변

eoyeong님, 안녕하세요!

트리 인덱스 구조를 이해하고 있다면, 무한 스크롤 쿼리는 어떻게 필요한 데이터에 대해서만 클러스터드 인덱스에 접근하는지 명확하게 파악할 수 있습니다.

동작 방식 자체가 offset을 스캔할 필요가 없이 기준점을 트리에서 바로 찾을 수 있으므로,

단순히 limit만큼 클러스터드 인덱스(데이터)에 접근하면 충분합니다.

하지만 페이지 번호 방식의 쿼리에서는,

기준점부터 페이징을 위해 offset만큼 반드시 스캔하면서 클러스터드 인덱스에 접근해야 하는데요,

위 과정에 대해 "커버링 인덱스로 동작하도록 DB가 알아서 최적화해주면 되지 않는가?" 라는 의문을 가질 수도 있을 것 같습니다.

사실 그 의문은 저도 있긴 한데요, 그렇게 동작하는 이유에 대해 DB 설계 철학까지 제가 모두 파악하고 있는건 아니다보니, 명확하게 말씀드리는건 어려움이 있네요.

다른 분이 유사한 질문을 남겼어서, 아래처럼 답을 드린 적이 있습니다.

참고 정도로 살펴보시면 좋을 것 같네요!

https://www.inflearn.com/community/questions/1480351/selet-all-%EC%BF%BC%EB%A6%AC%EC%97%90%EC%84%9C-%EB%B0%98%EB%B3%B5%EC%A0%81%EC%9C%BC%EB%A1%9C-clustered-index-%ED%83%90%EC%83%89-%ED%95%98%EB%8A%94%EC%A7%80-%EA%B6%81%EA%B8%88-%ED%95%A9%EB%8B%88%EB%8B%A4

안녕하세요, 인프런 AI 인턴입니다. eoyeong님.

SQL 쿼리에서 무한 스크롤과 페이지 넘버링 쿼리의 인덱스 사용 방식 차이와 관련된 질문에 대해 답변드리겠습니다. 이 문제는 데이터베이스 인덱스 사용의 본질과 관련이 있습니다.

왜 Clustered Index에 접근하는가

• 페이지 넘버링 쿼리: 이 쿼리는 일반적으로 LIMIT과 OFFSET을 사용하여 데이터를 가져옵니다. OFFSET 값을 건너뛰기 위해 시작부터 해당 위치까지 데이터를 확인해야 하는데, 이는 OFFSET이 클수록 성능 저하의 원인이 됩니다. 이 과정에서 먼저 Secondary Index에서 레코드 위치를 식별한 뒤, 실제 데이터를 가져오기 위해 Clustered Index에 접근하게 됩니다. 이는 SELECT *에서 모든 데이터 열이 필요하기 때문에 발생합니다.

• 무한 스크롤 쿼리: 반면 무한 스크롤 방식에서는 일반적으로 OFFSET 대신 WHERE 절에서 마지막으로 본 항목의 정보를 활용해 추가 데이터를 가져옵니다. 이는 인덱스 키에 의해 직접적인 액세스가 가능하게 하여 Clustered Index에 대한 불필요한 접근을 거의 하지 않도록 합니다. 무한 스크롤의 경우 현재 위치부터 다음 데이터를 가져오므로, 인덱스만으로 필요한 데이터를 효율적으로 찾을 수 있습니다.

해결 방법 및 최적화

• 인덱스 커버링: 필요한 열만을 SELECT하여, 인덱스 커버링이 가능하도록 설정하면 Clustered Index 접근을 줄일 수 있습니다.
  
• 페이징 전략 변경: 가능하다면 페이징 전략을 무한 스크롤 방식으로 변경하여 대량의 OFFSET 사용을 피하고 성능 최적화를 고려할 수 있습니다.
  

더 구체적인 정보를 원하신다면 인프런 커뮤니티에 있는 유사한 질문을 참고해보세요:

• 효율적인 페이징 및 인덱스 활용 굥기
  

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