Widok z funkcjami skalarnej wartości

Widok z funkcjami skalarnej wartości wywołuje je dla każdego wiersza, co może istotnie obciążać wydajność.

Jak widok korzysta z funkcji skalarnej

Widok z funkcjami skalarnej wartości to zapytanie zapisane w bazie danych, którego wynik zawiera wyrażenie zwracające jedną wartość dla każdego przetwarzanego wiersza. Funkcja skalarna może na przykład przekształcać tekst, obliczać wynik na podstawie kilku kolumn, normalizować kod produktu albo wyznaczać kategorię rekordu. W odróżnieniu od funkcji zwracającej tabelę nie dostarcza zbioru wierszy, lecz pojedynczy wynik typu zgodnego z jej definicją, taki jak liczba całkowita, tekst, data lub wartość logiczna reprezentowana przez typ dostępny w danym silniku.

Samo utworzenie widoku zwykle nie oznacza wykonania funkcji. Definicja widoku jest przechowywana jako zapytanie, a funkcja zostaje wywołana dopiero wtedy, gdy inne zapytanie odczytuje dane z tego widoku. Jeżeli zapytanie źródłowe zwraca tysiące wierszy, wyrażenie skalarne może zostać obliczone tysiące razy. Koszt zależy od treści funkcji, liczby odczytywanych kolumn, dostępu do dodatkowych tabel oraz sposobu, w jaki optymalizator zapytania potrafi połączyć funkcję z resztą instrukcji.

Dlaczego wywołanie dla każdego wiersza wpływa na plan wykonania

Funkcja skalarna wykonywana w projekcji widoku może działać jak ukryta operacja powtarzana dla każdego rekordu. Jeżeli funkcja zawiera wyłącznie proste działania arytmetyczne lub operacje na krótkim tekście, narzut może być niewielki. Inaczej wygląda sytuacja, gdy w jej wnętrzu znajduje się dodatkowe zapytanie, odczyt tabeli, przetwarzanie warunkowe albo kosztowna konwersja danych. Wtedy pojedynczy odczyt widoku może powodować serię kolejnych operacji, mimo że zapytanie użytkownika wygląda na proste.

Istotne jest również to, czy silnik bazy danych potrafi zoptymalizować funkcję, włączyć jej logikę do głównego planu wykonania lub wykonać obliczenia w sposób zbiorczy. Funkcja traktowana jako nieprzezroczysta jednostka może ograniczać optymalizatorowi możliwość przesuwania filtrów, wykorzystania indeksów i dobrania kolejności operacji. W konsekwencji warunek ograniczający liczbę wyników nie zawsze zmniejsza koszt funkcji tak skutecznie, jak sugerowałaby liczba zwróconych wierszy. Wymaga to sprawdzenia rzeczywistego planu wykonania, a nie tylko czasu odpowiedzi pojedynczego zapytania.

Objawy i sposób potwierdzenia kosztu

Problemy związane z takim widokiem mogą pojawić się jako długi czas odczytu, wysokie zużycie procesora, zwiększona liczba odczytów logicznych albo wyraźna różnica między zapytaniem korzystającym z widoku a zapytaniem odczytującym te same kolumny bez funkcji. Charakterystycznym sygnałem jest także pogorszenie wydajności po dodaniu kolejnej kolumny wyliczanej albo po zastosowaniu widoku w złączeniu z dużą tabelą. Sam fakt, że funkcja zwraca tylko jedną wartość, nie oznacza, że jej wykonanie jest tanie.

Weryfikację należy rozpocząć od odczytania definicji widoku i funkcji oraz ustalenia, jakie tabele i zapytania są używane pośrednio. Następnie warto uruchomić reprezentatywne zapytanie z typowym filtrem i porównać plan wykonania, czas, liczbę przetworzonych wierszy oraz zużycie zasobów z wariantem bez funkcji skalarnej. Należy uwzględnić zarówno pierwszy odczyt, jak i kolejne wykonania, ponieważ pamięć podręczna planu lub danych może zmieniać obserwowany czas. Pomiar powinien obejmować dane o rzeczywistej skali, a nie tylko mały lokalny zestaw testowy.

Przebudowa logiki bez utraty znaczenia wyniku

Jeżeli funkcja wykonuje operację możliwą do zapisania bezpośrednio w zapytaniu, można rozważyć zastąpienie jej wyrażeniem, warunkiem lub odpowiednio przygotowanym złączeniem. Taka zmiana może ułatwić optymalizatorowi analizę zależności między filtrem, indeksem i obliczeniem. Gdy funkcja wyszukuje dane pomocnicze, logiczną alternatywą bywa jawne złączenie z tabelą zawierającą te dane, o ile zachowane zostaną warunki dotyczące duplikatów, wartości pustych i braku dopasowania. Nie wolno jednak mechanicznie usuwać funkcji bez porównania wyników, ponieważ nawet drobna różnica w konwersji lub obsłudze wartości pustych może zmienić rezultat.

Przy projektowaniu widoku trzeba także sprawdzić, czy funkcja jest używana zawsze, czy tylko w określonych raportach lub formularzach. Jeżeli kosztowna kolumna jest potrzebna sporadycznie, korzystniejsze może być oddzielenie jej od podstawowego widoku albo obliczanie jej dopiero w zapytaniu, które faktycznie jej wymaga. Jeżeli wynik jest stały dla niezmiennych danych, można przeanalizować kontrolowane przechowywanie wartości wyliczonej, lecz należy wtedy zaplanować jej aktualizację po zmianie danych źródłowych. Po każdej modyfikacji trzeba porównać poprawność wyników, plan wykonania i obciążenie przy małej oraz dużej liczbie rekordów.