Ja , visninger kan har et klynget indeks tildelt, og når de gør det, gemmer de midlertidige resultater, der kan fremskynde resulterende forespørgsler.
Microsofts egen dokumentation gør det meget klart, at Views kan forbedre ydeevnen.
For det første er de fleste visninger, som folk opretter, enkle visninger og brug ikke denne funktion, og er derfor ikke anderledes end at forespørge direkte på basistabellerne. Simple visninger er udvidet på plads og bidrager derfor ikke direkte til ydeevneforbedringer - så meget er sandt. Men indekserede visninger kan dramatisk forbedre ydeevnen.
Lad mig gå direkte til dokumentationen:
Efter at et unikt klynget indeks er oprettet på visningen, materialiseres visningens resultatsæt øjeblikkeligt og bevares i fysisk lagring i databasen, hvilket sparer omkostningerne ved at udføre denne omkostningsfulde operation på udførelsestidspunktet.
For det andet kan disse indekserede visninger fungere selv når de ikke er direkte refereret af en anden forespørgsel da optimeringsværktøjet vil bruge dem i stedet for en tabelreference, når det er relevant.
Igen, dokumentationen:
Den indekserede visning kan bruges i en forespørgselsudførelse på to måder. Forespørgslen kan referere direkte til den indekserede visning, eller endnu vigtigere, forespørgselsoptimeringsværktøjet kan vælge visningen, hvis den bestemmer, at visningen kan erstatte en del af eller hele forespørgslen i den billigste forespørgselsplan. I det andet tilfælde bruges den indekserede visning i stedet for de underliggende tabeller og deres almindelige indekser. Visningen behøver ikke at blive refereret til i forespørgslen, for at forespørgselsoptimeringsværktøjet kan bruge det under udførelse af forespørgsel. Dette giver eksisterende applikationer mulighed for at drage fordel af de nyoprettede indekserede visninger uden at ændre disse applikationer.
Denne dokumentation samt diagrammer, der viser ydeevneforbedringer, kan findes her.
Opdatering 2: svaret er blevet kritiseret på baggrund af, at det er "indekset", der giver præstationsfordelen, ikke "View". Dette kan dog let afvises.
Lad os sige, at vi er en softwarevirksomhed i et lille land; Jeg vil bruge Litauen som eksempel. Vi sælger software over hele verden og opbevarer vores optegnelser i en SQL Server-database. Vi er meget succesrige, og så på få år har vi mere end 1.000.000 rekorder. Vi skal dog ofte indberette salg af skattemæssige årsager, og vi oplever, at vi kun har solgt 100 kopier af vores software i vores hjemland. Ved at oprette en indekseret visning af kun de litauiske poster, får vi opbevaret de poster, vi har brug for, i en indekseret cache som beskrevet i MS-dokumentationen. Når vi kører vores rapporter for salg i Litauen i 2008, vil vores forespørgsel søge gennem et indeks med en dybde på kun 7 (Log2(100) med nogle ubrugte blade). Hvis vi skulle gøre det samme uden VIEW og blot stole på et indeks i tabellen, ville vi skulle krydse et indekstræ med en søgedybde på 21!
Det er klart, at visningen i sig selv ville give os en ydeevnefordel (3x) i forhold til den simple brug af indekset alene. Jeg har forsøgt at bruge et eksempel fra den virkelige verden, men du vil bemærke, at en simpel liste over salg i Litauen ville give os en endnu større fordel.
Bemærk, at jeg bare bruger et lige b-træ til mit eksempel. Selvom jeg er ret sikker på, at SQL Server bruger en eller anden variant af et b-træ, kender jeg ikke detaljerne. Ikke desto mindre holder pointen.
Opdatering 3: Spørgsmålet er opstået om, hvorvidt en indekseret visning blot bruger et indeks placeret på den underliggende tabel. Det vil sige, for at parafrasere:"en indekseret visning er bare det, der svarer til et standardindeks, og det tilbyder intet nyt eller unikt for en visning." Hvis dette var sandt, så ville ovenstående analyse selvfølgelig være forkert! Lad mig give et citat fra Microsoft-dokumentationen, der viser, hvorfor jeg mener, at denne kritik ikke er gyldig eller sand:
Brug af indekser til at forbedre forespørgselsydeevne er ikke et nyt koncept; indekserede visninger giver dog yderligere ydeevnefordele, som ikke kan opnås ved brug af standardindekser.
Sammen med ovenstående citat vedrørende persistensen af data i fysisk lagring og anden information i dokumentationen om, hvordan indekser oprettes på Views, tror jeg, det er sikkert at sige, at en Indexed View er ikke blot en cachelagret SQL Select, der tilfældigvis bruger et indeks defineret på hovedtabellen. Derfor bliver jeg ved med at stå ved dette svar.