Czy zapytanie WHERE sprawdzi prostsze porównania (np. Bity) przed uruchomieniem bardziej uciążliwych porównań (np. Varchar)?

Jeśli napiszę zapytanie zawierające WHEREklauzulę złożoną, np .:

SELECT *
FROM MyTable
WHERE BitField = 1
    AND VarcharField = 'asdf'

a włączenie tego bitporównania po prostu wyklucza te same pola, varcharktóre wyklucza porównanie, czy obecność tego bitporównania pól poprawi mi wydajność?

Ważne jest, aby uznać, że SQL jest językiem deklaratywnym. SELECTZapytania napisałeś Określa wyników logicznych, które powinny być zwrócone. Mechanizm bazy danych, a konkretnie optymalizator zapytań, określa skuteczną strategię fizyczną zwracającą te wyniki.

Ostateczny fizyczny plan wykonania zależeć będzie od umiejętności rozumowania optymalizatora, czasu przygotowanego na problem, dostępności odpowiednich metod dostępu (głównie indeksów i zmaterializowanych widoków), reprezentatywnych informacji statystycznych oraz konkretnej ścieżki kodu specyfikacja zapytania przechodzi przez kod optymalizacji.

Ogólnie rzecz biorąc, jeśli projekt bazy danych jest relacyjny, zapewniasz dobre metody dostępu i dokładne informacje statystyczne, a zapytanie jest dobrze napisane, optymalizator zwykle znajdzie rozsądną fizyczną strategię wykonania bez potrzeby zbytniego martwienia się o pisemną formę zbyt duża specyfikacja zapytania.

Zawsze będą przypadki, w których wyrażenie tego samego wymogu logicznego przy użyciu innej (ale semantycznie identycznej) składni wpłynie na fizyczny plan wykonania, ale powinno to być drugorzędne. Ponownie, ogólnie, rozważ wyrażenie wyrażenia zapytania inaczej tylko wtedy, gdy charakterystyki środowiska wykonawczego są niedopuszczalne, po uwzględnieniu wszystkich wyżej wymienionych podstaw.

W ekstremalnych przypadkach rzadkie byłoby, gdyby pisemna kolejność prostych WHEREpredykatów klauzul łączących (jak w pytaniu) wpływała na fizyczny plan wykonania w jakikolwiek wymierny sposób. Krótko mówiąc, nie należy się tym martwić. Najpierw pobierz projekt bazy danych, indeksy i informacje statystyczne.

Aby odpowiedzieć na pytanie bezpośrednio (ostatecznie!), Dodanie dodatkowego warunku redundantnego może poprawić wydajność, ale tylko wtedy, gdy umożliwia użycie bardziej wydajnej metody dostępu - na przykład, jeśli istnieje tylko indeks (BitField, VarcharField). Gdyby już istniał indeks (VarcharField), dodawałby tylko narzut.

Jako szczegół implementacji nie, SQL Server nie bierze pod uwagę kosztów porównań w zależności od typu danych lub pozornej złożoności obliczeniowej. W rzeczywistości koszt operacji skalarnych w ogóle jest niewielki , ale prowadzi to do zupełnie odrębnego tematu.

Powiązane pytania:

Operatory logiczne LUB ORAZ w stanie i kolejności warunków w GDZIE
SQL Server 2008 i wyrażenia stałe
Operatory bitowe wpływające na wydajność
Dziwne zachowanie instrukcji SQL

Partycje binarne (jak kolumna bitowa) brzmią jak dobrzy kandydaci na przefiltrowane indeksy.

CREATE NONCLUSTERED INDEX MyTableWithBitFieldTrue
ON MyTable (VarcharField)
INCLUDE Id, <other columns you're selecting>
WHERE BitField = 1 ;
GO

Wyrażenie się na temat optymalizacji oznacza, że ​​kod jest bardziej odporny na zmiany innych osób, czy to w bazie kodu, czy w SQL Server.