그렇다면 해당하는 row값을 어떻게 찾는거야?
인덱스의 리프노드에는 해당하는 클러스터링의 포인터값(가르키는값을) 저장한다는데
그리고 클러스터링의 리프에 해당하는 데이터무더기값들 중에 해당하는 pk 행의 값을 전부 다들고오는거 아니엿어??
그 그럼 클러스터링 인덱스는 어떻게 그 행의 col들을 다 가져오는거야??
오늘 인덱스공부시작함
그렇다면 해당하는 row값을 어떻게 찾는거야?
인덱스의 리프노드에는 해당하는 클러스터링의 포인터값(가르키는값을) 저장한다는데
그리고 클러스터링의 리프에 해당하는 데이터무더기값들 중에 해당하는 pk 행의 값을 전부 다들고오는거 아니엿어??
그 그럼 클러스터링 인덱스는 어떻게 그 행의 col들을 다 가져오는거야??
오늘 인덱스공부시작함
커버링 인덱스가 뭔지부터 알아야
쿼리에 필요한 모든 컬럼이 인덱스에 포함된 인덱스라서 그런가
그럼 인덱스가 너무 커지지않아?
그러니까 일반적인 케이스가 아니지
아하.. 뭔가 참 간단한용이구나
커버링 인덱스 자체가 세컨더리 인덱스만 만으로도 쿼리 결과를 만들 수 있는거야. 세컨더리 인덱스의 컬럼과 pk 외에 추가적인 컬럼이 필요하면 그건 커버링 인덱스가 아니지 예를들어서 name 컬럼에 인덱스가 걸려있고 name, pk를 저장하는 세컨더리가 있을때 select name 혹은 select name, pk 처럼 세컨더리 인덱스 자체만으로 쿼리 결과 완성이 가능해야함
그럼 컬럼갯수가 엄청 적어야 가능한거아닌가요..?
그건 인덱스에 따라서 다르지 내가 든 예시는 하나의 컬럼으로만 인덱스를 만든거고 클러스터링 인덱스는 리프노드에 pk랑 해당 pk에 매칭되는 레코드 자체가 저장되어 있음 ㅇㅅㅇ
InnoDB 기준임 오라클은 rowid 기반으로 조작함
아 완벽히 이해했슴 ! ㄳ
그래서 인덱스를 함부로 만들지 말라는거 ㅇㅇ 막 만들면 너무 커지고 cud성능도 떨어지니까
INSERT/UPDATE/DELETE 할 때마다 모든 관련 인덱스 갱신되고 관리해야하는 B트리가 너무 많아지는게 리스크군요