작성자 없음
작성자 정보가 삭제된 글입니다.
작성
·
340
0
안녕하세요 :)
Q1)
Clustered Index 를 추가 한 뒤 Non Clustered Index의 변화를 살펴보면 PageID 값도 변하고 Heap Table이 사라짐에 따라 Heap RID도 변하게 됨을 확인했습니다.
궁금한 것은 강의 후반부 *18분 이후 내용입니다.
Heap Table이 사라져도 Non Clustered Index를 사용해서 테이블에 저장된 데이터를 찾게 될텐데, 강의중 말씀하신 고유한 key 값이란 무엇인가요? UNIQUIFIER를 말씀하신걸까요?
Q2-1)
Clustered Index를 추가하면 Non Clustered Index의 구조가 변하는 것은 확인을 했는데 이는 OrderID라는 공통 Index가 있어서 가능한 일 인 것 같습니다. 공통 Index가 없이 Clustered Index를 추가해도 구조에 변화가 생기게 되는지 궁금합니다.
Q2-2)
이어서 엉뚱한 질문을 드리면 Non Clustered Index 추가시 매커니즘을 보면
Non Clustered Index를 통해 고유한 Key 값 얻기 -> 고유한 Key 값으로 Clustered Page에서 Lookup
이와 같은 매커니즘인데 Non Clustered Index를 통해 얻은 고유한 Key값이 Clustered Page에서 데이터를 Lookup할 때 SCAN 가 아닌 SEEK을 한다는 보장이 있을까요? 다른 표현으로(맞는 표현일지는 모르겠지만...) Key값이 Clustered Page에서 Index로서의 역할을 제대로 할 수 있는건가요?
직전의 질문과도 연관이 있어보이는데 제 질문의 요점은 Non Clustered Index의 결과물을 Clustered Index의 Lookup에서 재사용하는 그림인데, 두 Index는 정의시 지정한 컬럼이 다른데 호환이 가능한지 궁금하네요.
감사합니다~
답변 1
2
1.
말 그대로 딱 1개만 있는 키를 말합니다.
uniquifier 자체는 고유하지 않고
강의 내용에선 (key) 가 붙은 3종 세트를 합한게 고유 키가 됩니다
경우에 따라 orderId/productId 가 unique하다면 uniquifier는 필요 없겠죠.
2.
1번에서 말한 clustered index의 고유키를 이용한다~ 만 이해하면 되고
세부적인 구현은 상황에 따라 다르기에 우리가 신경쓸 필요 없습니다.
DB 제품군마다 다를 수 있겠죠.
3.
2번과 연결되는 질문인데 clustered가 있는 구조에서, non-clustered에서 찾은 키는
clustered에서 사용하는 키로 찾을 수 있게 구현이 되어 있습니다.