Widok a wydajność zapytań

Widok nie przechowuje danych — jego wydajność zależy od zapytania i indeksów tabel leżących pod nim.

Widok jako warstwa logiczna nad tabelami

Widok w relacyjnej bazie danych jest zapisanym zapytaniem, które udostępnia wynik pod własną nazwą. Zwykły widok nie przechowuje osobnej kopii wierszy zwracanych przez zapytanie. Gdy aplikacja odczytuje dane z widoku, silnik bazy analizuje definicję widoku razem z zapytaniem wywołującym, a następnie pobiera potrzebne dane z tabel bazowych lub innych obiektów użytych w definicji. Z tego powodu samo utworzenie widoku zazwyczaj nie skraca czasu wykonywania zapytania.

Wydajność zależy od rzeczywistego planu wykonania. Znaczenie mają między innymi liczba odczytywanych wierszy, warunki filtrowania, sposób łączenia tabel, sortowanie, grupowanie oraz dostępne indeksy. Jeżeli widok łączy dużą tabelę z kilkoma innymi tabelami, to zapytanie korzystające z tego widoku może wymagać wykonania tych samych operacji co zapytanie zapisane bezpośrednio na tabelach. Widok porządkuje interfejs danych i może ograniczać dostęp do wybranych kolumn lub wierszy, ale nie jest automatycznie mechanizmem przyspieszającym.

Indeksy tabel bazowych i selektywność filtrów

Indeks powinien znajdować się na tabeli, z której silnik pobiera dane, a nie na samym zwykłym widoku. Przydatny indeks obejmuje kolumny używane w warunkach wyszukiwania, połączeniach tabel, sortowaniu albo grupowaniu, jeżeli jego struktura odpowiada konkretnym zapytaniom. Przykładowo, widok może zwracać zamówienia połączone z klientami, lecz filtr po identyfikatorze klienta będzie działał sprawnie tylko wtedy, gdy silnik może efektywnie znaleźć odpowiednie wartości w tabelach bazowych.

Sam fakt istnienia indeksu nie gwarantuje jego wykorzystania. Jeżeli warunek zwraca dużą część tabeli, odczyt wielu stron indeksu oraz późniejsze pobieranie danych może być droższe niż skan całej tabeli. Problemem może być także zastosowanie funkcji lub konwersji typu na kolumnie filtrowanej, ponieważ utrudnia to użycie zwykłego indeksu. Diagnostyka powinna więc obejmować porównanie zapytania z filtrem i bez filtra, sprawdzenie typów danych po obu stronach warunku oraz analizę liczby wierszy szacowanej i faktycznie odczytanej przez plan wykonania.

Plan wykonania, łączenia i ukryte koszty

Zapytanie odwołujące się do widoku może zawierać dodatkowe operacje wykonywane poza jego definicją. Przykładowo, zewnętrzne zapytanie może dodać kolejny filtr, sortowanie lub połączenie z następną tabelą. Optymalizator może przekształcić całość i przesunąć część warunków bliżej tabel źródłowych, ale rezultat zależy od konkretnego silnika, statystyk oraz konstrukcji zapytania. Nie należy zakładać, że każdy filtr zostanie automatycznie zastosowany na początku przetwarzania.

W planie wykonania warto zwrócić uwagę na skany dużych tabel, kosztowne sortowania, operacje grupowania, wielokrotne odczyty oraz połączenia powodujące zwielokrotnienie wierszy. Szczególnie istotne jest sprawdzenie, czy warunek łączenia używa kolumn o zgodnych typach i czy połączenie nie tworzy większej liczby wyników, niż przewiduje logika aplikacji. Zapytanie może być wolne także wtedy, gdy każdy pojedynczy odczyt wygląda poprawnie, lecz widok jest wywoływany wielokrotnie w pętli. W takim przypadku koszt narasta po stronie aplikacji, a poprawa wymaga ograniczenia liczby zapytań albo pobierania większego zestawu danych jednym wywołaniem.

Materializacja wyników i diagnostyka w praktyce

Jeżeli wynik musi być regularnie odczytywany, a jego obliczenie obejmuje kosztowne łączenia lub agregacje, można rozważyć mechanizm przechowujący wynik, o ile dany silnik bazy go obsługuje. Taki obiekt nie jest równoważny zwykłemu widokowi: zajmuje miejsce na dysku i wymaga odświeżania, aby zawartość odpowiadała tabelom źródłowym. Trzeba wtedy ustalić, czy aplikacja potrzebuje danych bieżących, czy dopuszczalne jest opóźnienie wynikające z harmonogramu odświeżania.

Rzetelna diagnostyka zaczyna się od zmierzenia czasu, liczby zwróconych wierszy i liczby odczytanych wierszy dla konkretnego zapytania. Następnie należy sprawdzić definicję widoku, zapytanie wywołujące, indeksy tabel bazowych, aktualność statystyk oraz plan wykonania. Test powinien używać reprezentatywnego rozmiaru danych, ponieważ zapytanie szybkie na małej bazie może zwolnić po jej rozbudowie. Przy serwisowaniu laptopów i komputerów PC warto odróżnić problem samego zapytania od ograniczeń sprzętowych, takich jak niewystarczająca ilość pamięci operacyjnej, wolny nośnik danych lub przeciążony procesor. Dopiero po takim rozdzieleniu można właściwie ocenić, czy potrzebna jest zmiana indeksu, uproszczenie zapytania, korekta modelu danych, materializacja wyniku czy diagnostyka komputera.