Clusterd일 경우 Index Seek가 느릴 수 없다.

NonClustered일 경우 데이터가 Leaf Page에 없다.

따라서 한번 더 타고 가야되는데

1) RID -> Heap Table (BookMark LookUp)

2) Key -> Clustered Index

이래된다.

---

실습을 해보자.

이런식이다. 이것을 두가지 방법으로 실행해보면

1번 방법의 경우

이렇게

2번방법의 경우

더 늘어났다!

따라서 항상 인덱스를 사용하는게 최선은 아니다!

상황에 따라서 달라진다!

---

Covered Index

---

그러면 조건1 AND 조건2 필요하면 무조건 INDEX -> Covered Index로 만들면 장떙??

-> 아니다. 꼭 그렇지는 않다.

-> DML연산을 할때 (INSERT, UPDATE, DELETE..)작업 부화 증가한다.

---

그래서 INCLUDE 사용해서 하면 NonClustered에서

추가적인 ShipVia정보를 들고있어줘서 룩업 하지않고 알아서 걸러지게된다.

---

결론

NonClustered Index가 악영향을 주는 경우?

• 북마크 룩업이 심각한 부과를 야기할 때

대안?

• 옵션1) Covered Index (검색할 모든 컬럼을 포함 하겠다)
• 옵션2) Index에다가 Include 힌트를 남긴다.
• 옵션3) Clustered Index사용한다.(테이블당 1개 궁극기)