Czy kolejność klauzul ma znaczenie w SQL?

Powiedzmy, że mam tabelę PEOPLEo nazwie mająca 3 kolumny ID, LastName, FirstName, żadna z tych kolumn nie jest indeksowana.
LastNamejest bardziej wyjątkowy i FirstNamemniej wyjątkowy.

Jeśli przeprowadzę 2 wyszukiwania:

select * from PEOPLE where FirstName="F" and LastName="L" 
select * from PEOPLE where LastName="L" and FirstName="F"

Uważam, że to drugie jest szybsze, ponieważ bardziej unikalne kryterium ( LastName) znajduje się na pierwszym miejscu w whereklauzuli, a rekordy będą eliminowane skuteczniej. Nie sądzę, aby optymalizator był wystarczająco inteligentny, aby zoptymalizować pierwszy plik sql.

Czy moje rozumienie jest prawidłowe?

Nie, ta kolejność nie ma znaczenia (a przynajmniej: nie powinna mieć znaczenia).

Każdy przyzwoity optymalizator zapytań przeanalizuje wszystkie części WHEREklauzuli i znajdzie najbardziej efektywny sposób spełnienia tego zapytania.

Wiem, że optymalizator zapytań SQL Server wybierze odpowiedni indeks - bez względu na to, w jakiej kolejności masz dwa warunki. Zakładam, że inne RDBMS będą miały podobne strategie.

Liczy się to, czy masz do tego odpowiedni indeks!

W przypadku SQL Server najprawdopodobniej użyje indeksu, jeśli masz:

• indeks na (LastName, FirstName)
• indeks na (FirstName, LastName)
• indeks tylko (LastName)lub tylko (FirstName)(lub obu)

Z drugiej strony - znowu dla SQL Server - jeśli użyjesz SELECT *do pobrania wszystkich kolumn z tabeli, a tabela jest raczej mała, istnieje duża szansa, że ​​optymalizator zapytań po prostu wykona skanowanie tabeli (lub indeksu klastrowego) zamiast używać indeks (ponieważ wyszukiwanie na pełnej stronie danych w celu uzyskania wszystkich innych kolumn staje się zbyt drogie, bardzo szybko).

Kolejność klauzul WHERE nie powinna mieć wpływu na bazę danych zgodną ze standardem SQL. W większości baz danych kolejność ocen nie jest gwarantowana.

Nie myśl, że SQL dba o kolejność. Poniższe generuje błąd w programie SQL Server:

select *
from INFORMATION_SCHEMA.TABLES
where ISNUMERIC(table_name) = 1 and CAST(table_name as int) <> 0

Gdyby pierwsza część tej klauzuli została wykonana jako pierwsza, wówczas tylko numeryczne nazwy tabel byłyby rzutowane jako liczby całkowite. Jednak kończy się to niepowodzeniem, dając jasny przykład, że SQL Server (podobnie jak w przypadku innych baz danych) nie dba o kolejność klauzul w instrukcji WHERE.

ANSI SQL Draft 2003 5WD-01-Framework-2003-09.pdf

6.3.3.3 Kolejność oceny reguł

...

Tam, gdzie pierwszeństwo nie jest określone przez formaty lub nawiasy, efektywna ocena wyrażeń jest zwykle wykonywana od lewej do prawej. Jednak od implementacji zależy, czy wyrażenia są faktycznie oceniane od lewej do prawej, szczególnie gdy operandy lub operatory mogą powodować podniesienie warunków lub jeśli wyniki wyrażeń można określić bez całkowitego oceniania wszystkich części wyrażenia.

skopiowane stąd

Nie, wszystkie RDBM najpierw zaczynają się od analizy zapytania i optymalizują je przez zmianę kolejności klauzuli where.

W zależności od tego, którego RDBM używasz, możesz wyświetlić wynik analizy (na przykład wyszukaj plan wyjaśnienia w Oracle)

M.

Oryginalne oświadczenie OP

Uważam, że to drugie jest szybsze, ponieważ bardziej unikalne kryterium (LastName) znajduje się na pierwszym miejscu w klauzuli Where, a rekordy zostaną efektywniej wyeliminowane. Nie sądzę, aby optymalizator był wystarczająco inteligentny, aby zoptymalizować pierwszy plik sql.

Myślę, że mylisz to z wyborem kolejności kolumn podczas tworzenia indeksów, w których najpierw musisz umieścić bardziej selektywne kolumny niż drugie najbardziej selektywne i tak dalej.

BTW, dla powyższych dwóch zapytań optymalizator serwera SQL nie dokona żadnej optymalizacji, ale użyje planu Trivila, o ile całkowity koszt planu jest mniejszy niż koszt progowy równoległości.

To prawda, zakładając, że nazwiska nie są indeksowane. Jednak inne dane mogą być błędne. Aby dowiedzieć się, w jaki sposób to zrobić, który może się różnić za każdym razem, DBMS musiałby uruchomić odrębne zapytanie zliczające dla każdej kolumny i porównać liczby, co kosztowałoby więcej niż zwykłe wzruszanie ramionami i kontynuowanie.