Odpowiedź.

Indeksowany widok (Indexed View, materializowany widok z indeksem) — to widok (VIEW), dla którego został utworzony unikalny indeks klastrowy. Umożliwia to fizyczne przechowywanie wyników zapytania na dysku i wykorzystanie indeksu do przyspieszenia dostępu.

Zalety:

• Szybkie pobieranie zagregowanych lub często używanych danych.
• Redukcja obciążenia przy obliczeniach w czasie rzeczywistym.

Ograniczenia:

• Nie wszystkie typy zapytań są wspierane (na przykład nie można używać typów danych TEXT, NTEXT, IMAGE, niektóre funkcje).
• Dodatkowe koszty utrzymania indeksu przy zmianach w tabeli podstawowej.
• Wymaga przestrzegania zestawu ścisłych zasad przy deklaracji.

Przykład kodu

CREATE VIEW dbo.SalesSummary WITH SCHEMABINDING AS
   SELECT SalesPersonID, COUNT_BIG(*) AS SalesCount, SUM(TotalDue) AS TotalDue
   FROM dbo.Sales
   GROUP BY SalesPersonID;
GO
CREATE UNIQUE CLUSTERED INDEX idx_SalesSummary 
   ON dbo.SalesSummary (SalesPersonID);

Pytanie z podstępną pułapką.

P: Czy wszystkie widoki pozwalają na stworzenie na sobie indeksu (klastrowego)?

O: Nie, można indeksować tylko te VIEW, które w pełni spełniają ograniczenia (na przykład nie ma zewnętrznych odwołań, funkcje agregujące są zgodne itd.). W przeciwnym razie zapytanie o stworzenie indeksu zwróci błąd.

Przykłady rzeczywistych błędów z powodu nieznajomości szczegółów tematu.

---

Historia

W realnym projekcie w systemie bankowym konieczne było przyspieszenie zapytań na podstawie agregowanych raportów. Utworzyli indeksowany VIEW bez analizy obciążenia przy aktualizacji tabel. Przy masowych operacjach wstawiania wydajność tabeli głównej gwałtowanie spadła z powodu znacznych kosztów związanych z aktualizacją indeksu widoku.

---

Historia

Specjalista błędnie zakładał, że można indeksować VIEW z określonym JOIN na zewnętrznej tabeli i funkcją GETDATE(). Zapytanie o stworzenie indeksu zakończyło się błędem „Nie można utworzyć indeksu na widoku z funkcjami niedeterministycznymi”. Poświęcono dzień na poprawę architektury projektu.

---

Historia

W dużym projekcie e-commerce aktualizacja danych w tabeli podstawowej „Products” spowodowała powstanie blokad. Przyczyna — nieprawidłowe zarządzanie transakcjami przy istnieniu dużego indeksowanego VIEW, w którym agregacja obejmowała miliony wierszy.