북마크 룩업 강의에서 12:10 부분에서 질문드립니다.

Question

1. 첫번째 질문입니다. NonClustered Index로 Index Seek를 하더라도  느릴 수 있는 이유가 RID값을 가지고 Heap Table에서 RID Lookup을 하는데, 데이터가 메모리에 없으면 하드디스크에서 가져와야 하기 때문에 느리다고 하셨는데, 그것은 비교대상인 Table Scan쪽도 마찬가지 아닌가 하는 생각이 듭니다. 그래서 NonClustered Index로 Index Seek를 하더라도 느릴 수 있는 이유가 될 수 없다는 생각이 듭니다. 2. 두번째 질문입니다. 결론 부분에서 Nonclustered Index가 악영향을 주는 이유가 북마크 룩업이 심각한 부하를 야기할 때라고 하셨는데, 북마크 룩업에서 심각한 부하를 일으키는 경우가 예시로 설명해주신 CustomerID와 ShipVia를 함께 검색하는 부분에서, ShipVia와 일치하는 정보를 찾기 위해 ShipVia가 일치하지 않는 Leaf Page까지  모두 검색해야 하는데, 이미 ShipVia가 어느 Leaf Page에 있는 지 알고 있는 경우와 비교했을 때 Leaf Page를 뒤지는(북마크 룩업) 행위가 더 많기 때문에 부하가 많은 거라고 이해했습니다. 그래서 북마크 룩업으로 인해 NonClusteredIndex가 느릴 수 있다. 라고 이해했습니다. 그래서 북마크룩업을 수행하긴 하는데 필요한부분만 진행하도록 인덱스를 만들어야 한다고 이해했습니다. 잘 이해했나요?

Rookiss · Answer

1. 특별히 Table Scan이 비교대상은 아니고, NonClustered 자체에 대한 얘기입니다.
Clustered는 물리적으로 데이터가 있는 순서를 그대로 검색하니 추가적인 검색이 필요하지 않은데,
경우에 따라 NonClustered는 추가 검색의 비용이 만만치 않을 수도 있다, 는 이론적 배경입니다.
데이터가 없으면 하드에서 갖고 오는건 당연할 수도 있지만
1개의 데이터가 필요하다고 딱 '그' 데이터만 갖고 오는 것은 아니라는게 핵심입니다.
즉, OS와 마찬가지로 DB에서도 큼지막하게 페이지 단위로 주변 데이터까지 갖고 옵니다.
운 좋게 Table Scan을 하고 있어서 갖고 온 데이터 덩어리에
우리가 원하는 데이터가 많이 뭉쳐 있으면 그걸 다 사용하면 되겠지만,
반대로 데이터 덩어리에 우리가 찾는 데이터가 딱 1개 뿐이라면,
나머지는 버리고 또 다시 디스크 접근을 할 수밖에 없게 됩니다.
그러니 사탕 꾸러미에서 사탕을 1개씩 갖고 오느냐,
큰 손으로 사탕을 100개씩 갖고 오느냐의 차이 정도로 볼 수 있습니다.
따라서 NonClustered Index가 걸려 있다고 해도 무조건 만능은 아니라는 것입니다.
<< 이론적으로는 위와 같긴 한데 사실 DBA가 아닌 일반 응용 개발자 입장에서
이런 부분까지 크게 신경쓰진 않긴 합니다.

이길호 · Answer

자세한 답변 너무 감사드립니다!! 덕분에 확실히  이해했습니다.