위 글 본문은 개소리고
댓글에서 인덱스 얘기하다가 아키텍처에 대한
얘기가 나왔는데
그때 결론 내렸던게 포인터를 가질경우
실제 클러스터드 인덱스 키값의 변경에 대한
논클러스터드 인덱스 변경 작업에 자유로운 대신
Read에서 모든 논클러스터드 인덱스가 룩업 연산을
필수로 하여야 하기때문에
실제 서비스의 대부분이 Read가 압도적이므로
Read에 유리하도록 논클러스터드의 리프페이지가 포인터가 아닌
실제 값을 저장하고 include를 지원하도록 한게 아닌가?
로 마무리 되었는데 더 알아보니
실제 클러스터드 인덱스 값을 가지는게 유리한 이유가
하나 더있는게 클러스터드 인덱스의 Page Split(페이지가 꽉찼으나 해당 페이지가 가지고있는 도메인 구간의 데이터 삽입 및 수정작업)이 일어날때 논클러스터드 인덱스가 포인터를 가지고있다면 split된 페이지에 해당하는 레코드들은
모든 논클러스터드 인덱스에서 포인터정보를 새로 고쳐줘야 하기 때문에 실제 값을 가지게 된듯
- dc official App
오.. 그럴듯하네
해당 댓글은 삭제되었습니다.
ㅇㅇㅇㅇㅇ - dc App
1. ㅇㅇ 2. 비즈니스가 매번 모든데이터를 조회 하는경우에는 클러스터드 인덱스가 필요없음 단건조회, 조건조회하려면 클러스터드 인덱스 있는게 무조건 유리하겠지? 아니면 힙테이블이라고하는 무정렬된 구조에서 풀스캔을 해야하기때문 그리고 DBA가 없다면 그걸 설계하는것도 개발자 몫임 - dc App
스플릿은 정상적인 프로세스임 스캔연산시 물리적 페이지 정렬순서와 논리적 페이지 정렬 순서를 일치시키도록 하기 위한 내부 프로세스니까 대부분의 경우 신경안써도돼 - dc App
돈내놔 - dc App
?? 윗글 본문이 틀리다고?innodb 인데?
커버링인덱스에 대한 설명이 틀림 - dc App
사실상 포함됐다고 봐도 되는거 아냐?
커버링 인덱스 개념은 아닌데 맞는말 아님?
ㅈㅁ 정리해서 얘기해봄 - dc App
커버링 인덱스라는 개념은 DML을 작성할때의 관점에서그 구문에 적합한 인덱스를 커버링 인덱스라고 하는걸로암그래서 pk가 대부분의 비즈니스 로직에서커버링 인덱스 이므로 pk로 작성된것이나새로운 비즈니스가 추가되거나 기존 비즈니스가 변경되었을때 그 비즈니스에서는 커버링 인덱스가 아닐 수 있음커버링 인덱스냐 아니냐가 중요한 이유는해당테이블에 대해 추가적인 연산이 필요한지에대한 내용이기때문 - dc App
혹시 내가 틀렸다고 생각하는게 있으면 피드백점.. - dc App
+ 논클러스터드 인덱스로 데이터를 탐색하는데 해당 인덱스에 포함되지 않는 속성 도 조회하거나 조건에 존재할경우 LookUp연산이 필요한데 이경우 커버링 인덱스가 아님 - dc App
인덱스 리프노드는 pk다 == 커버링 인덱스에는 pk가 포함돼있다 단순 이 소리 아냐? 별 의미는 없는 소리다만
일단 저글 쓴놈은 그게맞는듯 그리고 글의 본문은 맞고 제목은 틀림 - dc App
논클러스터 인데스를 가진 컬럼을 기준으로 검색할때, 논 클러스터 인덱스 페이지에서 원하는 컬럼 값을 찾고 -> 그 값에 해당하는 pk를 얻음 -> 실제 테이블를 read 이런 방식임?
너가짠 쿼리구문에 사용되는 속성이 논클러스터드 인덱스만으로 커버가 안되면 클러스터드 인덱스에 룩업연산하는거임 ㅇㅇ - dc App
그래서 단건조회 기준 논커버링 인덱스는 커버링 인덱스 io의 약 두배 가량 나옴 B-Tree를 두번 탐색하여야 하기때문에 - dc App
야 통찰력 있노 배워간다