해결된 질문
작성
·
130
0
안녕하세요 좋은 강의 감사드립니다~
게시글 목록 조회시
select * from article
where board_id = 1
order by article_id desc
limit 30 offset 1499970;
1.여기 쿼리문에서 where 절이 먼저 실행되어 (board_id, article_id) 생성된 secondary Index 에서 board_id = 1 인 데이터들을 찾아서
2.어차피 article_id 도 정렬이 되어 있으니 이 부분에서 offset 을 순차적으로 skip 하면서 결국에 마지막에
3.select * 문을 수행하는게 아닌가요?
2번 과정에서 order by article_id 를 위해 clusterd Index 에서 데이터를 조회하는 과정이 추가되나요?
> 게시글 목록 API - 페이지 번호 기반 - N번 페이지, M개 게시글 - 설계
> 20:07
마지막에 최종적으로 select * 문을 조회할때만 clusterd Index 에서 데이터를 조회하는거 아닌가요? 왜냐하면 이미
secondary Index 에서 article_id 가 정렬되어 있기 때문에 그냥 skip 하고 마지막에만 clusterd Index 에서 데이터를 조회할 것 같습니다.
답변 2
3
은경님, 안녕하세요!
일단 강의 잘 수강해주셔서 감사합니다!
스킵하는 과정에 대해 세컨더리 인덱스만 태울 수 있으면 좋겠지만, 현재는 클러스터드 인덱스도 반드시 거쳐가고 있습니다.
그렇기 때문에 offset이 커질수록 스킵하는 비용도 커지다보니 성능 이슈가 발생하게 되는 것이고요.
그렇다면, 세컨더리 인덱스만 타도 충분한 상황에, 왜 항상 클러스터드 인덱스만 타는지 궁금하실 수 있을 것 같습니다.
InnoDB의 동작이 왜 이렇게 만들어졌냐고 묻는다면..
사실 제가 데이터베이스 개발자는 아니다보니, 이러한 설계 방향에 대해서까지 명쾌하게 답변 드리긴 쉽지 않네요.. ㅎㅎㅎ
이론 상 가능하긴 하지만, 설계 일관성 측면에서 특정 케이스에 대해서만 최적화하기에는 어려움이 있지 않았을까 싶기도 합니다.
이전에도 다른 분도 유사한 질문을 주신 적이 있는데요,
제대로 된 답변을 드리진 못 했었지만.. 참고 정도로만 살펴보셔도 좋을 것 같습니다!
0
안녕하세요, 인프런 AI 인턴입니다. 황은경님.
질문하신 OFFSET 기반의 페이징 쿼리에서 인덱스를 어떻게 활용하는지 설명드리겠습니다. 이 쿼리는 데이터베이스 성능 최적화와 관련이 있습니다.
잘못된 생각: Secondary Index에서 모든 것을 처리
WHERE
절과 ORDER BY
절은 Secondary Index에서 처리할 수 있는 부분입니다. 여기서 board_id
에 맞는 데이터를 찾고, article_id
로 정렬된 상태로 데이터를 순차적으로 찾아갑니다.현실: Clustered Index로의 접근이 필요
SELECT *
는 테이블의 모든 컬럼을 가져오는 쿼리로, 이 경우 데이터베이스는 필요 데이터가 Secondary Index에만 있지 않는다는 점에서 실제 데이터 레코드를 위해 Clustered Index에 접근해야 합니다.OFFSET
을 처리하기 위해, 대량의 행을 건너뛰어야 하기 때문에 실제 데이터 위치에 대한 정보를 가져오기 위해 Clustered Index를 사용합니다.관련해서 다른 사용자가 질문한 유사한 질문이 있어 소개합니다. 이 게시물이 도움될 수 있습니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.