Dane wyjściowe EXPLAIN PLAN są danymi wyjściowymi debugowania optymalizatora zapytań Oracle. COST jest końcowym wynikiem działania optymalizatora opartego na kosztach (CBO), którego celem jest wybranie, który z wielu różnych możliwych planów powinien zostać użyty do uruchomienia zapytania. CBO oblicza względny koszt dla każdego planu, a następnie wybiera plan o najniższym koszcie.
(Uwaga:w niektórych przypadkach CBO nie ma wystarczająco dużo czasu, aby ocenić każdy możliwy plan; w takich przypadkach wybiera po prostu plan o najniższym dotychczas stwierdzonym koszcie)
Ogólnie rzecz biorąc, jednym z największych czynników przyczyniających się do powolnego zapytania jest liczba wierszy odczytanych w celu obsługi zapytania (a dokładniej mówiąc, blokowania), więc koszt będzie oparty częściowo liczby wierszy, które należy odczytać z oszacowań optymalizatora.
Załóżmy na przykład, że masz następujące zapytanie:
SELECT emp_id FROM employees WHERE months_of_service = 6;
(months_of_service kolumna ma ograniczenie NOT NULL i zwykły indeks.)
Optymalizator może wybrać tutaj dwa podstawowe plany:
- Plan 1:Odczytaj wszystkie wiersze z tabeli „pracownicy”, dla każdego sprawdź, czy predykat jest prawdziwy (
months_of_service=6). - Plan 2:Przeczytaj indeks, gdzie
months_of_service=6(powoduje to zestaw ROWID), a następnie uzyskaj dostęp do tabeli na podstawie zwróconych ROWID.
Wyobraźmy sobie, że tabela „pracownicy” ma 1 000 000 (1 milion) wierszy. Wyobraźmy sobie dalej, że wartości dla months_of_service mieszczą się w zakresie od 1 do 12 i z jakiegoś powodu są dość równomiernie rozłożone.
Koszt Planu 1 , który obejmuje PEŁNE SKANOWANIE, będzie kosztem odczytania wszystkich wierszy w tabeli pracowników, co w przybliżeniu wyniesie 1 000 000; ale ponieważ Oracle często będzie w stanie odczytać bloki za pomocą odczytów wieloblokowych, rzeczywisty koszt będzie niższy (w zależności od konfiguracji bazy danych) - np. wyobraźmy sobie, że liczba odczytów wieloblokowych wynosi 10 - obliczony koszt pełnego skanowania wyniesie 1 000 000 / 10; Koszt całkowity =100 000.
Koszt Planu 2 , który obejmuje SKANOWANIE ZAKRESU INDEKSU i wyszukiwanie tabeli według ROWID, będzie kosztem skanowania indeksu plus koszt dostępu do tabeli według ROWID. Nie będę zagłębiać się w koszt skanowania zakresu indeksu, ale wyobraźmy sobie, że koszt skanowania zakresu indeksu wynosi 1 na wiersz; spodziewamy się znaleźć dopasowanie w 1 na 12 przypadków, więc koszt skanowania indeksu wynosi 1 000 000 / 12 =83 333; plus koszt dostępu do tabeli (załóżmy, że 1 blok odczytu na dostęp, nie możemy tutaj użyć odczytów wieloblokowych) =83 333; Całkowity koszt =166 666.
Jak widać, koszt Planu 1 (pełne skanowanie) jest MNIEJSZY niż koszt Planu 2 (skan indeksu + dostęp przez wierszid) - co oznacza, że CBO wybrałoby pełne skanowanie.
Jeśli założenia przyjęte przez optymalizatora są prawdziwe, to w rzeczywistości Plan 1 będzie lepszy i znacznie bardziej wydajny niż Plan 2 – co obala mit, że PEŁNE skany są „zawsze złe”.
Wyniki byłyby zupełnie inne, gdyby celem optymalizatora było FIRST_ROWS(n) zamiast ALL_ROWS – w takim przypadku optymalizator preferowałby Plan 2, ponieważ często zwraca on pierwsze kilka wierszy szybciej, kosztem mniejszej wydajności całego zapytania .
