실행계획에서 인덱스에 대한 Seek연산을 볼수있는데 해당 연산에서 Seek연산만으로 끝나면 커버링인덱스 인것이고 조건자 연산이 더붙으면 커버링 인덱스가 아닌것임 조건자가 붙었다는건 Seek연산 이후 결과물을 가지고 필터링을 했다는것으로 이는 비즈니스로직에 핏하게 인덱스가 존재하지 않아서 불필요한 io가 발생한것임 - dc official App
Pk를 포함하는 쿼리에 pk를 포함하지 않는 복합 인덱스로 쿼리를 사용하면 innodb의 경우 리프노드에서 pk를 확인할 수있어 클러스터 인덱스로 조회가 불필요해져서 pk는 커버링인덱스에 항상 포함된다가 맞는거 아님?
일단 말이 좀 이상하게 써지신것 같은데 논클러스터드 인덱스를 타면 논클러스터드 인덱스의 키와 pk 키값을 포함하면 결국 추가연산이 필요 없어져서 커버링인덱스가 되지 않냐? 인거죠? - dc App
ㅇㅇㅇ 그말인데
진짜루 간단하게 설명하자면예시로 1번부터 6번까지 컬럼이 있을때-1,2로 클러스터드 인덱스(pk)-3,4로 논클러스터드 인덱스있다고 쳤을때 님말마따나 3,4컬럼으로조건걸고 1,2,3,4속성을 조회하면 이건 커버링인덱스인데5나6을 포함하면 클러스터드 인덱스의리프페이지 탐색을해야해서 룩업 연산이 발생해요논클러스터드 인덱스에는 해당값이 없기때문 - dc App
그치
제목에 항상이라 쓴게 문제였네
근데 5,6 컬럼을 포함한다면 애초에 커버링 인덱스란 전제에서 어긋나는거 아닌가?
위에 예시는 논클러스터드 인덱스의 룩업으로인한 커버링인덱스가 아닌예시고 pk가 항상 커버링인덱스가 아닌예시는 이글 본문이에요 - dc App
그렇죠 커버링인덱스라는건 애초에 그테이블을 탐색하는 dml을 기준으로 얘기하는거라 - dc App
커버링 인덱스를 판단하는 주체는 인덱스 키가 아니라 해당인덱스를 사용할 dml이 주체에오 - dc App
Pk로 인한 추가 연산이 왜 필요한지 궁금함
Select pk, 3,4 from ~~ where 3 = and 4= 같은 쿼리면 pk를 위한 추가연산이 필요없이 논클러스터 인덱스만으로 처리가능한게 커버링인덱스 아닌가요?
넹 맞음 아까제가쓴 예시가 그 말인디.. 줄 넘기기가 안되서 이상하게 보였나요?? 1,2가 클러스터드이고 3,4가 논클러스터드 인덱스일때 3,4에 조건걸고 1~4내에서만 조회하면 커버링인덱스라고... - dc App
5.6 을 조회해서 커버링인덱스가 아닌거면 애초에 커버링 인덱스가 아닌 쿼리인거지 커버링 인덱스에 항상 pk 가 포함된다는 말이 그럼 왜틀린지 몰겟어요
잠만 기다려봐요 씻는중인데 왜 커버링인덱스를 얘기할때 인덱스 스키마가 아닌 DML을 기준으로 얘기해야하는지 제 견해를 정리해서 드리겠습니다 - dc App
ㅇㅇ 방금 집들어와서 저도 씻고옴
글로 따로 정리했는데 한번 확인해보 - dc App