Select 조회를 할 때 내부 DB 흐름 질문
안녕하세요.
select * from article where board_id= 1 order by article_iddesc limit 30 offset 90;해당 쿼리문을 날렸을 때의 문제점을 설명하는 부분에서 이해가 잘 가지 않는 부분이 있어 질문드립니다!
제가 기억하는 내용이 틀릴 수도 있어 질문드립니다!
제가 알고있던 바로는 Secondary index에 의해 만들어진 자료구조에서 leaft노드는 원본 데이터의 주솟값을 가진다고 알고있었습니다.
따라서 강의의 설명에서는 article id를 가지고 다시 clustered index를 통해 조회한다 했지만 바로 O(1)으로 원본 데이터에 접근한다는 이해는 틀린것일까요? 틀렸다면 어떤 부분일까요?
좋은 강의 잘 듣고있습니다! 감사드립니다!
학습 관련 질문을 최대한 상세히 남겨주세요!
고민 과정도 같이 나열해주셔도 좋습니다.
먼저 유사한 질문이 있었는지 검색해보세요.
인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.
답변 2
0
dohyeong254님, 안녕하세요!
클러스터드 인덱스와 세컨더리 인덱스의 자료구조는 모두 트리로 이루어져 있습니다.
그리고 세컨더리 인덱스의 리프 노드는 원본 데이터에 접근할 수 있는 식별자, 즉 Primary Key를 가지고 있습니다.
실제 주솟값을 가진게 아닌, 논리적으로 포인터 역할을 하는 Primary Key를 통해 클러스터드 인덱스에서 데이터를 찾을 수 있는 것입니다. (주솟값 가진건 MyISAM 스토리지 엔진이랑 혼동하신 것 같기도 하네요!)
Primary Key로 클러스터드 인덱스에 접근하여 데이터를 찾아나가는 과정은,
트리의 시간복잡도 O(logN)의 시간이 필요합니다!
1
아 정말 감사드립니다!! 답변을 기반으로 더 찾아보고 공부하니 이제 완벽히 이해가 되었습니다!!
좋은 강의 감사드리고 빠른 답변 감사드립니다!! 좋은 하루 되시길 바라겠습니다 😊😊
0
안녕하세요, 인프런 AI 인턴입니다. dohyeong254님.
질문하신 내용은 데이터베이스의 인덱스 작동 방식, 특히 Secondary Index와 Clustered Index의 관계 및 역할에 대한 부분입니다. 인덱스가 어떻게 작동하는지를 이해하는 것은 성능 최적화 측면에서 매우 중요합니다.
Secondary Index와 Clustered Index의 이해
Secondary Index:
- Secondary Index는 특정 컬럼에 대한 인덱스를 형성하여 검색을 빠르게 수행할 수 있게 합니다.
- 인덱스의 리프 노드(leaf node)는 실제 데이터를 가리키는 포인터(주소) 정보를 가지고 있어, 인덱스가 가리키는 데이터가 바로 조회 가능한 상황을 만듭니다.
- Secondary Index는 특정 컬럼에 대한 인덱스를 형성하여 검색을 빠르게 수행할 수 있게 합니다.
Clustered Index:
- Clustered Index는 실제 데이터가 저장된 장소입니다. InnoDB에서는 기본 키가 기본적으로 Clustered Index로 사용됩니다.
- 데이터베이스는 SELECT * 문을 통해 전체 레코드를 가져오는 경우, Secondary Index로 찾은 레코드의 주소 정보를 이용해 Clustered Index로의 접근이 필요해집니다.
- Clustered Index는 실제 데이터가 저장된 장소입니다. InnoDB에서는 기본 키가 기본적으로 Clustered Index로 사용됩니다.
쿼리의 실행 과정
- 쓸모 있는 인덱스 검사:
WHERE board_id = 1조건 때문에, 해당 조건을 만족하는 레코드의 위치를 찾기 위해 Secondary Index를 활용합니다.
- 데이터 접근: 그 후, 찾은 위치 정보를 통해 Clustered Index에서 실제 데이터를 접근하여 SELECT * 문에서 요구하는 모든 컬럼을 가져옵니다.
이는 즉, Secondary Index가 실제 데이터를 직접적으로 탐색(접근)하기보다는 필요한 데이터를 가리키는 역할만을 한다는 것을 의미합니다. 데이터베이스는 이러한 과정을 통해 불필요한 전체 테이블 스캔을 피할 수 있으나, OFFSET 과 같이 많은 레코드를 건너뛰어야 하는 경우에는 여전히 성능 저하가 발생할 수 있습니다.
관련해서 인프런 커뮤니티에서 유사한 질문과 답변이 있으니, 참고하시면 도움이 될 것입니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
@Version 어노테이션이 붙은 필드는 낙관적 락이든 비관적 락이든 업데이트가 됩니다.
0
31
1
consumer에서 에러가 발생할 경우 데이터 유실 문의
0
47
2
게시글 테스트 데이터 삽입
0
50
2
정렬, 필터, 검색 등의 조건이 붙을 경우 최적화할 수 있는 방법이 무엇이 있을까요?
0
103
2
좋아요 기능 정합성 보장 방법
0
96
2
좋아요 동시성처리 최적의 선택?
1
135
2
프론트엔드 msa 환경 api 주소 통합? 과 서버끼리 통신 방식에대해
0
91
2
안녕하세요 무한스크롤 강의듣다가 질문이 있습니다.
0
59
1
조회수 조회 로직 질문
1
67
2
비로그인 유저도 어뷰징 방지 정책
1
72
2
CommentServiceTest의 테스트 로직 질문
0
54
2
무한 스크롤 방식에서 페이지 번호 방식 쿼리의 문제점 의문
1
74
2
path 쿼리 관련 질문드립니다!
0
59
2
antigravity 에디터를 쓰신다면 종료해주세요
1
123
0
프로젝트 구조
0
88
2
article_like_count api test
0
77
2
이벤트 페이로드 객체의 생성 방식이 팩토리 메서드 패턴이 아닌 빌더 패턴인 이유가 궁금합니다!.
0
104
2
[33. 좋아요 수 구현] 에서 테스트 하는 화면 동시성 문제
0
90
2
findByPath에서 articleId로도 검색을 해야 할 것 같아요.
0
91
3
jpa ddl-auto none을 하는 이유와 join 방법
0
97
2
팩터리 메소드와 response 객체 사용 이유가 궁금합니다!
0
90
2
커서 기반 페이지네이션 과 무한 스크롤링
0
109
2
게시글 생성 로직에서 오류 발생시 redis 게시글 수 되돌리기
0
97
2
멀티 모듈이 아닌 MSA 환경에서 common
0
156
2