Dlaczego wykonywane jest skanowanie tabeli?

Question

SELECT X.ID, X.Field4 
FROM 
     #TaxInvoiceData T 
INNER JOIN 
     xxx X 
     ON T.Id = X.Id 
     AND Field2 = @VAR  
     AND Field3 = 'S' 

Kiedy uruchomić kwerendę pełną tabelę skanowania w tabeli X. Nie rozumiem dlaczego, bo klucz podstawowy tabeli X jest

ID INT ASC 
Field3 CHAR(2) ASC 
Field2 DATETIME ASC Unique Non-clustered 

Istnieje również indeks

Field2 DATETIME ASC Non-Unique Non-clustered 

robi tylko

SELECT ID 
FROM xxx 
WHERE 
    Field2 = @VAR 
AND Field3 = 'S' 

Czy Indeksem Szukajcie

Z góry dziękuję.

Answer 1

Krótka odpowiedź: ponieważ optymalizator uważa byłoby szybciej.

Spróbujmy jednak przeczytać umysł optymalizatora.

Ponieważ nie podano pełnego schematu tabeli, zakładam, że istnieje indeks klastrowany na xxx.ID i że #TaxInvoiceData jest stertą. Oczekujesz planu, w którym indeks PK jest badany dla każdego wiersza w #TaxInvoiceData, ale wybierasz xxx.Field4, który będzie wymagał wyszukiwania zakładek dla każdego dopasowania. Może to spowodować 29 000 losowych żądań we/wy. Oooo.

Odwrotnie, SQL Server może (i najwyraźniej będzie) wykonać większą liczbę bardziej wydajnych operacji wejścia/wyjścia, wykonując skanowanie tabeli i prawdopodobnie wykona szybki skrót z #TaxInvoiceData.

Co więc można zrobić? Możesz utworzyć indeks obejmujący Field4. Lub możesz użyć indeksu i dołączyć wskazówki, aby wymusić plan, którego szukasz (ale podejrzewam, że wydajność nie byłaby tak dobra, jak masz nadzieję). Czy to zapytanie jest używane na tyle często, że daje problemy z wydajnością aplikacji lub po prostu chcesz wyeliminować skanowanie tabeli z zasady? Jeśli to drugie, może się okazać, że narzut pozbycia się skanu nie jest w końcu wart.

---

Edit:

Skoro już wspomniałem, że nie ma indeksu klastrowego na stole, to również może mieć wpływ na sposób efektywny wyszukiwań z indeksu są. Jeśli ta tabela nie jest bardzo obciążona, należy rozważyć zmianę PK w klastrze. Już samo to może zmienić plan, a nawet jeśli nie przyspieszy innych operacji z powodu zmniejszenia narzutów.

Answer 2

Może przepisanie zapytania pomogłoby:

SELECT X.ID, X.Field4 
FROM xxx X, #TaxInvoiceData T 
WHERE X.Id = T.Id   
AND X.Field2 = @VAR    
AND X.Field3 = 'S'