Zakładam również, że używasz Oracle. Na początek polecam również zapoznanie się ze stroną internetową planu wyjaśnień. Optymalizacja jest dużo, ale można się jej nauczyć.
Oto kilka wskazówek:
Po pierwsze, gdy ktoś zleca Ci optymalizację, prawie zawsze szuka akceptowalnej wydajności, a nie najwyższej wydajności. Jeśli możesz skrócić czas działania zapytania z 3 minut do 3 sekund, nie przejmuj się skracaniem go do 2 sekund, dopóki nie zostaniesz o to poproszony.
Po drugie, wykonaj szybkie sprawdzenie, aby upewnić się, że optymalizowane zapytania są logicznie poprawne. Brzmi to absurdalnie, ale nie mogę powiedzieć, ile razy proszono mnie o poradę w sprawie wolno działającego zapytania, tylko po to, by dowiedzieć się, że od czasu do czasu podawał złe odpowiedzi! Jak się okazuje, debugowanie zapytania często okazywało się również przyspieszać jego działanie.
W szczególności poszukaj wyrażenia „Dołączanie kartezjańskie” w planie wyjaśniania. Jeśli to tam zobaczysz, są bardzo duże szanse, że znalazłeś niezamierzone sprzężenie kartezjańskie. Typowym wzorcem niezamierzonego złączenia kartezjańskiego jest to, że klauzula FROM wymienia tabele oddzielone przecinkami, a warunki złączenia znajdują się w klauzuli WHERE. Tyle że brakuje jednego z warunków złączenia, więc Oracle nie ma innego wyjścia, jak wykonać złącze kartezjańskie. Przy dużych stołach jest to katastrofa wydajności.
W planie wyjaśniania można zobaczyć sprzężenie kartezjańskie, w którym zapytanie jest logicznie poprawne, ale kojarzę to ze starszymi wersjami Oracle.
Poszukaj także nieużywanego indeksu złożonego. Jeśli pierwsza kolumna indeksu złożonego nie jest używana w zapytaniu, Oracle może użyć indeksu nieefektywnie lub wcale. Podam przykład:
Zapytanie brzmiało:
select * from customers
where
State = @State
and ZipCode = @ZipCode
(DBMS nie był Oracle, więc składnia była inna i zapomniałem oryginalnej składni).
Szybki rzut oka na indeksy ujawnił indeks klientów z kolumnami (Kraj, Stan, Kod pocztowy) w tej kolejności. Zmieniłem zapytanie na przeczytane
select * from customers
where Country = @Country
and State = @State
and ZipCode = @ZipCode
a teraz działał w około 6 sekund zamiast około 6 minut, ponieważ optymalizator był w stanie wykorzystać indeks z dobrą korzyścią. Zapytałem programistów aplikacji, dlaczego pominęli kraj w kryteriach i to była ich odpowiedź:wiedzieli, że wszystkie adresy mają kraj równy 'USA', więc uznali, że mogą przyspieszyć zapytanie, pomijając to kryterium!
Niestety, optymalizacja pobierania z bazy danych to nie to samo, co skrócenie czasu obliczeniowego o mikrosekundy. Obejmuje to zrozumienie projektu bazy danych, zwłaszcza indeksów, oraz przynajmniej omówienie sposobu, w jaki optymalizator wykonuje swoją pracę.
Zwykle uzyskujesz lepsze wyniki dzięki optymalizatorowi, gdy uczysz się z nim współpracować, zamiast próbować go przechytrzyć.
Powodzenia w szybkiej optymalizacji!
