Jak interpretujesz plan wyjaśnienia zapytania?

Przy próbie zrozumienia sposobu wykonywania instrukcji SQL czasami zaleca się przyjrzenie się planowi wyjaśniania. Jaki jest proces, przez który należy przejść przy interpretacji (nadaniu sensu) planu wyjaśniania? Co powinno się wyróżniać jako „Och, to działa znakomicie?” w przeciwieństwie do „O nie, to nie w porządku”.

Wzdrygam się, gdy widzę komentarze, że pełne tablesany są złe, a dostęp do indeksu dobry. Pełne skanowanie tabel, skanowanie zakresu indeksów, szybkie pełne skanowanie indeksów, zagnieżdżone pętle, łączenie przez scalanie, łączenie mieszające itp. To po prostu mechanizmy dostępu, które muszą być zrozumiane przez analityka i połączone ze znajomością struktury bazy danych i celu zapytania w aby dojść do jakiegokolwiek sensownego wniosku.

Pełne skanowanie jest po prostu najskuteczniejszym sposobem odczytu dużej części bloków segmentu danych (tabeli lub tabeli (pod) partycji) i chociaż często może wskazywać na problem z wydajnością, to tylko w kontekście czy jest to skuteczny mechanizm do osiągnięcia celów zapytania. Mówiąc jako hurtownik danych i facet z BI, moją flagą numer jeden ostrzegawczą dotyczącą wydajności jest metoda dostępu oparta na indeksach i zagnieżdżona pętla.

Tak więc, jeśli chodzi o mechanizm czytania planu wyjaśniającego, dobrym przewodnikiem jest dokumentacja Oracle: http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009

Przeczytaj również Przewodnik po dostrajaniu wydajności.

Znajdź także wyszukiwarkę „informacji zwrotnej o liczności”, techniki, w której plan wyjaśniania może być użyty do porównania oszacowań liczności na różnych etapach zapytania z rzeczywistymi licznościami doświadczanymi podczas wykonywania. Moim zdaniem autorem metody jest Wolfgang Breitling.

Podsumowując: poznaj mechanizmy dostępu. Zapoznaj się z bazą danych. Zrozum intencję zapytania. Unikaj praktycznych zasad.

Temat jest zbyt obszerny, aby odpowiedzieć na takie pytanie. Poświęć trochę czasu na przeczytanie Przewodnika optymalizacji wydajności Oracle

Poniższe dwa przykłady przedstawiają PEŁNE skanowanie i SZYBKIE skanowanie przy użyciu INDEKSU.

Najlepiej jest skoncentrować się na koszcie i liczności. Patrząc na przykłady, użycie indeksu zmniejsza koszt wykonania zapytania.

Jest to trochę bardziej skomplikowane (i nie mam 100% uchwytu), ale zasadniczo Koszt jest funkcją kosztu procesora i IO, a kardynalność to liczba wierszy, które Oracle spodziewa się przeanalizować. Zmniejszenie obu tych elementów jest dobrą rzeczą.

Nie zapominaj, że na koszt zapytania może wpływać zapytanie i model optymalizatora Oracle (np. KOSZT, WYBIERZ itp.) Oraz częstotliwość przeprowadzania statystyk.

Przykład 1:

SKANUJ http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b

Przykład 2 przy użyciu indeksów:

INDEKS http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b

I jak już sugerowano, uważaj na TABLE SCAN. Zasadniczo można ich uniknąć.

Szukanie rzeczy, takich jak skanowanie sekwencyjne, może być nieco przydatne, ale rzeczywistość tkwi w liczbach ... z wyjątkiem sytuacji, gdy liczby są tylko szacunkowe! To, co jest zwykle znacznie bardziej przydatne niż przeglądanie planu kwerend , to przyglądanie się faktycznemu wykonaniu . W Postgres jest to różnica między EXPLAIN a EXPLAIN ANALYZE. EXPLAIN ANALYZE faktycznie wykonuje zapytanie i pobiera rzeczywiste informacje o czasie dla każdego węzła. Dzięki temu możesz zobaczyć, co się naprawdę dzieje, zamiast tego, co myśli planista się wydarzy. Wiele razy okaże się, że skanowanie sekwencyjne w ogóle nie stanowi problemu, zamiast tego jest czymś innym w zapytaniu.

Drugim kluczem jest określenie, jaki jest rzeczywisty kosztowny krok. Wiele narzędzi graficznych będzie używać strzałek o różnej wielkości, aby wskazać, ile kosztują różne części planu. W takim przypadku po prostu szukaj stopni, na które wchodzą cienkie strzały i gruba strzała wychodząca. Jeśli nie używasz GUI, musisz przyjrzeć się liczbom i poszukać miejsca, w którym nagle stają się znacznie większe. Przy odrobinie praktyki dość łatwo jest wskazać problematyczne obszary.

Naprawdę w przypadku takich problemów najlepszą rzeczą do zrobienia jest ASKTOM . W szczególności jego odpowiedź na to pytanie zawiera odsyłacze do internetowego dokumentu Oracle, w którym wyjaśniono wiele tego rodzaju reguł.

Należy pamiętać, że plany wyjaśniania to naprawdę najlepsze domysły.

Dobrym pomysłem byłoby nauczenie się używania sqlplus i eksperymentowanie z poleceniem AUTOTRACE. Z niektórymi twardymi liczbami możesz ogólnie podejmować lepsze decyzje.

Ale powinieneś ASKTOM. Wie o tym wszystko :)

Wynik wyjaśnienia informuje, jak długo trwał każdy krok. Pierwszą rzeczą jest znalezienie kroków, które zajęły dużo czasu i zrozumienie, co one oznaczają. Takie rzeczy, jak skanowanie sekwencyjne, mówią, że potrzebujesz lepszych indeksów - jest to głównie kwestia badania konkretnej bazy danych i doświadczenia.

Jedno „O nie, to nie w porządku” często ma postać skanu tabeli . Skanowanie tabel nie wykorzystuje żadnych specjalnych indeksów i może przyczynić się do wyczyszczenia wszystkich przydatnych w pamięci podręcznej pamięci. Na przykład w PostgreSQL wygląda to tak.

Seq Scan on my_table  (cost=0.00..15558.92 rows=620092 width=78)

Czasami skanowanie tabel jest idealne w przypadku, na przykład, używania indeksu do wykonywania zapytań dotyczących wierszy. Jest to jednak jeden z tych wzorów czerwonej flagi, których szukasz.

Zasadniczo przyglądasz się każdej operacji i sprawdzasz, czy operacje "mają sens", biorąc pod uwagę twoją wiedzę o tym, jak powinna ona działać.

Na przykład, jeśli łączysz dwie tabele, A i B w ich odpowiednich kolumnach C i D (AC = BD), a Twój plan przedstawia skanowanie indeksu klastrowego (termin SQL Server - brak pewności co do terminu wyroczni) w tabeli A, a następnie połączenie zagnieżdżonej pętli z serią indeksów klastrowych w tabeli B, możesz pomyśleć, że wystąpił problem. W tym scenariuszu można by oczekiwać, że aparat wykona parę skanowań indeksów (po indeksach w połączonych kolumnach), po których nastąpi sprzężenie przez scalanie. Dalsze badanie może ujawnić złe statystyki, które zmuszają optymalizator do wybrania tego wzorca łączenia lub indeksu, który w rzeczywistości nie istnieje.

spójrz na procent czasu spędzony w każdej podsekcji planu i zastanów się, co robi silnik. na przykład, jeśli skanuje tabelę, rozważ umieszczenie indeksu w polu (polach), które jest skanowane

Szukam głównie indeksów lub skanów tabel. Zwykle oznacza to, że brakuje mi indeksu w ważnej kolumnie znajdującej się w instrukcji where lub instrukcji join.

Z http://www.sql-server-performance.com/tips/query_execution_plan_analysis_p1.aspx :

Jeśli zobaczysz którykolwiek z poniższych elementów w planie wykonania, powinieneś wziąć pod uwagę je jako znaki ostrzegawcze i zbadać je pod kątem potencjalnych problemów z wydajnością. Każdy z nich nie jest idealny z punktu widzenia wydajności.

* Index or table scans: May indicate a need for better or  additional indexes.
* Bookmark Lookups: Consider changing the current clustered index,
  consider using a covering index, limit
  the number of columns in the SELECT
  statement.
* Filter: Remove any functions in the WHERE clause, don't include wiews
  in your Transact-SQL code, may need
  additional indexes.
* Sort: Does the data really need to be sorted? Can an index be used to
  avoid sorting? Can sorting be done at
  the client more efficiently? 

Nie zawsze można ich uniknąć, ale im bardziej można ich uniknąć, tym szybsza będzie wydajność zapytań.

Reguły kciuka

(prawdopodobnie chcesz też poczytać o szczegółach:

• Oracle Docs
• ASKTOM
• Dokumentacja SQL Server
  )

Zły

Skany kilku dużych tabel

Dobry

Korzystanie z unikalnego indeksu
Indeks zawiera wszystkie wymagane pola

Najczęstsza wygrana

W około 90% problemów z wydajnością, które widziałem, najłatwiejszym sposobem jest rozbicie zapytania z wieloma (4 lub więcej) tabelami na 2 mniejsze zapytania i tabelę tymczasową.