추가 열이 클러스터 된 인덱스에 의해 고유하게 결정될 때 인덱스 커버

Question

lutab에서 mytab을 다음과 같이 업데이트해야한다고 가정 해 봅시다.

update myTab
  set LookupVale = (select LookupValue from luTab B
                                       where B.idLookup = myTab.idLookup)

Lutab은 2 개의 열 (Idlookup (고유), LookupValue)로 구성됩니다.

바람직한 것은 다음과 같습니다 : Idlookup의 고유 한 클러스터 인덱스 또는 Idlookup 및 LookupValue의 하나는 결합됩니까? 커버링 지수 가이 상황에서 어떤 차이를 만들 것인가?

(저는 주로 SQL Server에 관심이 있습니다)

---

에필로그 :

나는 MyTab에서 27m 줄, Lutab에서 1.5m 줄로 아래의 KRIPS 테스트를 추적했다. 중요한 부분은 지수의 독창성 인 것 같습니다. 인덱스가 고유 한 것으로 지정되면 업데이트는 해시 테이블을 사용합니다. 고유 한 것으로 지정되지 않은 경우 업데이트는 먼저 Idlookup (Stream Aggegate)에 의해 Lutab을 Aggreat 후 중첩 루프를 사용합니다. 이것은 훨씬 느립니다. 확장 인덱스를 사용할 때 SQL은 더 이상 LookupValue가 독특하다고 가정하지 않으므로 훨씬 느리고 스트림 집계 네그리케이션 루프 경로를 강요했습니다.

Answer 1

나는 당신의 테이블을 만들었고 몇 개의 레코드 만로드했습니다 (50 개 정도의 조회, MyTab에서 15).

그런 다음 다양한 인덱스 옵션을 시도했습니다. Lutab에 대한 지수는 항상 29%입니다.

흥미로운 점은 Lutab의 인덱스에 LookupValue 열을 추가하면 실행 계획이 인덱스를 찾은 후 두 가지 추가 단계를 보여줍니다 : 스트림 집계 및 Assert. 비용은 0%이지만 더 많은 데이터로 증가 할 수 있습니다.

또한 IDLOOKUP에 대한 비 클러스터 인덱스를 시도했으며 LookUpValue를 '포함 된 열'으로 포함 시켰습니다. 이렇게하면 해당 열을 검색하기 위해 데이터 페이지에 액세스 할 필요가 없습니다. 실행 계획에 다른 것을 보여주지 않지만 (그러나 스트림 집계 / 어제도 없음) 이는 옵션 일 수 있습니다.

-Krip

Answer 2

첫째 :

• 덮개 지수는 항상 클러스터되지 않습니다
• 항상 PK와 클러스터 된 인덱스가 있어야합니다 (SQL Server에서 기본적으로 동일합니다).

2 개의 개념은 별도입니다

그래서:

• 당신의 pk (클러스터)는 독창적으로 행을 식별하면 idlookup입니다.
• 커버링 인덱스는 (idlookup)을 포함합니다 (LookupValue)

하지만:

• idlookup은 PK (클러스터)이므로 덮개 인덱스가 필요하지 않습니다.
• 클러스터 된 인덱스 (PK)는 클러스터 된 인덱스의 특성에 의해 암시 적으로 "커버링"됩니다 (간단히, 색인은 가장 낮은 수준의 데이터입니다)