Widok indeksowany

Widok indeksowany fizycznie przechowuje wynik zapytania, przyspieszając odczyt kosztem dodatkowego miejsca.

Widok indeksowany a zwykły widok logiczny

Widok indeksowany jest obiektem bazy danych opartym na zapytaniu, którego wynik może zostać zapisany w fizycznych strukturach indeksowych. Zwykły widok logiczny przechowuje przede wszystkim definicję zapytania. Gdy aplikacja odwołuje się do takiego widoku, silnik bazy danych zwykle wykonuje jego zapytanie na podstawowych tabelach i indeksach. Widok indeksowany może natomiast udostępnić wcześniej obliczone wiersze, dzięki czemu część pracy potrzebnej podczas odczytu została wykonana już wcześniej.

Nie oznacza to, że widok indeksowany jest niezależną kopią danych pozostawioną bez kontroli. Jeżeli zmieni się tabela źródłowa, silnik musi odpowiednio zmienić również dane utrzymywane dla widoku albo odrzucić możliwość użycia nieaktualnej struktury. Sposób tworzenia, ograniczenia definicji, automatyczne dopasowanie zapytania i wymagania dotyczące indeksu zależą od konkretnego systemu zarządzania bazą danych. Dlatego przed wdrożeniem trzeba sprawdzić dokumentację używanego silnika, zamiast zakładać, że mechanizm działa identycznie w każdym produkcie.

Jak fizyczne przechowywanie wyniku wpływa na odczyt

Korzyść z widoku indeksowanego pojawia się przede wszystkim wtedy, gdy zapytanie wielokrotnie wykonuje kosztowne operacje. Dotyczy to między innymi łączenia dużych tabel, filtrowania wielu wierszy, grupowania, obliczania agregatów oraz odczytu kolumn potrzebnych w raportach. Jeżeli wynik jest dostępny w odpowiednio zaprojektowanym indeksie, silnik może odczytać znacznie mniej danych niż podczas każdorazowego przeliczania całego zapytania źródłowego. Mniejsza liczba operacji odczytu i obliczeń może skrócić czas odpowiedzi oraz zmniejszyć obciążenie procesora.

Widok indeksowany nie przyspiesza automatycznie każdego zapytania. Optymalizator musi uznać, że użycie tej struktury jest tańsze od odczytu tabel bazowych. Znaczenie mają między innymi selektywność filtrów, aktualne statystyki, rozmiar tabel, dostępne indeksy oraz plan wykonania. Jeśli zapytanie zwraca niewiele danych z małej tabeli, dodatkowa struktura może nie dać zauważalnej korzyści. W niektórych silnikach zapytanie musi także odwoływać się bezpośrednio do widoku, a w innych optymalizator może wykorzystać jego indeks bez zmiany treści zapytania. Jest to cecha konkretnej implementacji, którą należy potwierdzić testem planu wykonania.

Koszt utrzymania przy zmianach danych

Fizyczny wynik widoku wymaga miejsca na dysku, stron danych, metadanych i indeksów. Im większy wynik oraz im więcej kolumn obejmuje struktura, tym większy może być koszt przechowywania. Dodatkowe miejsce trzeba uwzględnić przy planowaniu pojemności oraz kopii zapasowych. Indeks widoku może również zwiększać zużycie pamięci podręcznej, ponieważ jego strony konkurują o zasoby z tabelami i innymi indeksami.

Najważniejszym kompromisem jest wpływ zmian w tabelach bazowych. Przy operacji wstawiania, aktualizacji lub usuwania danych silnik może musieć zmodyfikować nie tylko tabelę źródłową, lecz także reprezentację wyniku widoku i powiązane indeksy. Częste modyfikacje dużych tabel mogą więc wydłużyć zapis, zwiększyć liczbę operacji wejścia-wyjścia oraz powodować dodatkowe blokady. Z tego powodu widok indeksowany jest bardziej uzasadniony dla danych często odczytywanych i stosunkowo rzadko zmienianych albo dla zapytań raportowych, których koszt obliczenia jest wysoki. Przed utworzeniem obiektu warto porównać czas odczytu i zapisu, rozmiar bazy oraz plany wykonania na danych zbliżonych do produkcyjnych.

Weryfikacja poprawności i dobór rozwiązania

Diagnostyka widoku indeksowanego powinna rozpocząć się od sprawdzenia definicji zapytania, zależności między tabelami i warunków, w których wynik jest używany. Należy porównać rezultat widoku z zapytaniem wykonanym bezpośrednio na tabelach źródłowych, zwracając uwagę na filtry, wartości puste, typy danych, zaokrąglenia oraz sposób działania agregacji. Różnica wyników może wskazywać na błąd definicji, niezgodne warunki połączenia albo niewłaściwe założenia dotyczące aktualizacji danych. Sam fakt, że zapytanie działa szybciej, nie potwierdza jeszcze jego poprawności.

W praktyce warto obserwować czas odpowiedzi, odczyty logiczne i fizyczne, zużycie procesora, koszt operacji zapisu oraz rozmiar dodatkowych struktur. Po zmianie indeksów, statystyk, schematu tabel lub rozkładu danych wcześniejsza korzyść może się zmniejszyć. W systemie laptopowym lub biurowym problem z wolnym działaniem aplikacji może wynikać również z dysku, pamięci RAM, sterownika albo konfiguracji połączenia z bazą, a nie z samego widoku. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego przy problemach ze stacją roboczą można oddzielić usterkę sprzętową od opóźnienia wynikającego z pracy oprogramowania bazodanowego.