it-swarm.dev

SQL Server Dołącz / gdzie zlecenie przetwarzania

Po przeczytaniu Wolne zapytanie SQL, nie jestem pewien, jak zoptymalizować , pomyślałem o ogólnej wydajności zapytań. Z pewnością potrzebujemy, aby wyniki pierwszej tabeli (gdy połączone są inne tabele) były możliwie jak najmniejsze przed dołączeniem (złączenia wewnętrzne dla tego pytania), aby nasze zapytania były nieco szybsze.

Przykład:

SELECT *
FROM   ( SELECT * FROM table1 WHERE col = @val ) t
INNER JOIN table2 ON col = col2

Bądź lepszy/szybszy niż:

SELECT *
FROM table1
INNER JOIN table2 ON col = col2
WHERE table1.col = @val

Moja teoria jest następująca (może to nie być poprawna implementacja, próbuję zapamiętać z przeczytanej książki o SQL Server 2008 (MSFT Press)):

  1. Procesor zapytań najpierw pobiera lewą tabelę (tabela1)
  2. Dołącza do drugiej tabeli (tabela 2) i tworzy produkt kartezjański przed odfiltrowaniem niezbędnych wierszy (jeśli dotyczy)
  3. Następnie wykonuje klauzule WHERE, ORDER BY, GROUP BY, HAVING z instrukcją SEELCT jako ostatnią.

Jeśli więc w powyższym zestawieniu nr 1 tabela jest mniejsza, silnik SQL ma mniej pracy przy tworzeniu produktów kartezjańskich. Następnie po osiągnięciu instrukcji where masz ograniczony zestaw wyników do filtrowania w pamięci.

Mógłbym być tak daleko od znaku, że to nierealne. Tak jak powiedziałem, to teoria.

Twoje myśli?

Uwaga : Właśnie pomyślałem o tym pytaniu i nie miałem jeszcze okazji przeprowadzić żadnych testów.

Uwaga 2 : Oznaczono jako SQL Server, ponieważ nie wiem cokolwiek o implementacji MySql itp. Proszę poczuć w każdym razie swobodnie odpowiadać/komentować

18
Stuart Blackler

Logiczne przetwarzanie zapytania odbywa się na MSDN (napisane przez zespół Microsoft SQL Server, a nie firmy zewnętrzne)

1. FROM
2. ON
3. JOIN
4. WHERE
5. GROUP BY
6. WITH CUBE or WITH ROLLUP
7. HAVING
8. SELECT
9. DISTINCT
10. ORDER BY
11. TOP

Tabela pochodna podąża za tym, a następnie zapytanie zewnętrzne robi to ponownie itp. Itd

Jest to logiczne chociaż: nie rzeczywiste . Bez względu na to, jak SQL Server to robi, semantyka jest honorowana do litery. „Rzeczywisty” jest określany przez Optymalizator zapytań (QO) i unikasz wspomnianego pośredniego produktu Cartesion.

Warto wspomnieć, że SQL jest deklaratywny: mówisz „co”, a nie „jak”, jak w przypadku programowania proceduralnego/imperatywnego (Java, .net). Zatem powiedzenie „dzieje się to wcześniej” jest w wielu przypadkach błędne (np. Założenie, że występują zwarcia lub kolejność L-do-R, GDZIE)

W powyższym przypadku QO wygeneruje ten sam plan, bez względu na jego strukturę, ponieważ jest to proste zapytanie.

Jednak QO opiera się na kosztach i w przypadku złożonego zapytania wygenerowanie idealnego planu może zająć 2 tygodnie. Więc robi to „wystarczająco dobrze”, co tak naprawdę nie jest.

Twój pierwszy przypadek może pomóc optymalizatorowi w znalezieniu lepszego planu, ponieważ logiczna kolejność przetwarzania jest inna dla 2 zapytań. Ale może nie.

Użyłem tej sztuczki w SQL Server 2000, aby uzyskać 60-krotną poprawę wydajności w zapytaniach dotyczących raportowania. Ponieważ QO ulepsza wersję do wersji, staje się coraz lepszy w rozwiązywaniu tych problemów.

I wspomniana książka: istnieje spór
Patrz SO i kolejne linki: https://stackoverflow.com/q/3270338/27535

16
gbn

Zapytanie SQL nie ma charakteru proceduralnego, nie ma przetwarzania od góry do dołu operatorów łączenia. Kolejność tabel w przykładowych zapytaniach nie ma wpływu na plan wykonania , ponieważ są one logicznie równoważne i wygenerują dokładnie ten sam plan.

W pewnym sensie oceniasz dwie opcje optymalizator zapytań podczas generowania planu dla tego zapytania. Podstawowym czynnikiem wpływającym na wybór planu jest statystyki dla zaangażowanych tabel i koszty związane z wyborami operatora w dowolnych planach kandydujących.

Bardzo proste łączenie dwóch tabel, takie jak twój przykład, może być usatysfakcjonowane jednym z setek różnych planów wykonania. Optymalizator decyduje, który będzie najlepszy sposób na odpowiedź na zapytanie, porównując koszty tych planów.

Czasami robi się źle i możesz pomóc w dokonywaniu lepszych wyborów poprzez ulepszone indeksowanie, aktualizowanie statystyk i stosowanie wskazówek. W bardzo rzadkich przypadkach możesz wymusić kolejność wykonywania przy użyciu podpowiedzi FORCE ORDER, ale należy tego używać oszczędnie. To młotek do zgryzienia orzecha, optymalizator zwykle może zostać wprowadzony do generowania lepszych planów poprzez dostarczanie lepszych informacji.

6