Ja , vyer kan har ett klustrat index tilldelat och när de gör det kommer de att lagra tillfälliga resultat som kan påskynda resulterande frågor.
Microsofts egen dokumentation gör det mycket tydligt att Views kan förbättra prestandan.
För det första är de flesta vyer som människor skapar enkla visningar och använder inte den här funktionen, och skiljer sig därför inte från att fråga direkt i bastabellerna. Enkla vyer utökas på plats och bidrar därför inte direkt till prestandaförbättringar - så mycket är sant. Men indexerade vyer kan dramatiskt förbättra prestandan.
Låt mig gå direkt till dokumentationen:
Efter att ett unikt klustrat index har skapats på vyn materialiseras vyns resultatuppsättning omedelbart och bevaras i fysisk lagring i databasen, vilket sparar omkostnader för att utföra denna kostsamma operation vid körning.
För det andra kan dessa indexerade vyer fungera även när de inte direkt refereras av en annan fråga eftersom optimeraren kommer att använda dem i stället för en tabellreferens när så är lämpligt.
Återigen, dokumentationen:
Den indexerade vyn kan användas i en frågekörning på två sätt. Frågan kan referera till den indexerade vyn direkt, eller, ännu viktigare, frågeoptimeraren kan välja vyn om den bestämmer att vyn kan ersätta en del av eller hela frågan i den billigaste frågeplanen. I det andra fallet används den indexerade vyn istället för de underliggande tabellerna och deras vanliga index. Vyn behöver inte hänvisas till i frågan för att frågeoptimeraren ska kunna använda den under utförande av en fråga. Detta gör att befintliga applikationer kan dra nytta av de nyskapade indexerade vyerna utan att ändra dessa applikationer.
Den här dokumentationen, såväl som diagram som visar prestandaförbättringar, finns här.
Uppdatering 2: svaret har kritiserats utifrån att det är "indexet" som ger prestandafördelen, inte "vyn". Detta är dock lätt motbevisat.
Låt oss säga att vi är ett mjukvaruföretag i ett litet land; Jag ska använda Litauen som exempel. Vi säljer mjukvara över hela världen och förvarar våra register i en SQL Server-databas. Vi är mycket framgångsrika och på några år har vi över 1 000 000 rekord. Men vi behöver ofta rapportera försäljning i skattesyfte och vi upptäcker att vi bara har sålt 100 exemplar av vår programvara i vårt hemland. Genom att skapa en indexerad vy av bara de litauiska posterna får vi behålla de poster vi behöver i en indexerad cache som beskrivs i MS-dokumentationen. När vi kör våra rapporter för försäljning i Litauen 2008 kommer vår fråga att söka igenom ett index med ett djup på bara 7 (Log2(100) med några oanvända blad). Om vi skulle göra samma sak utan VIEW och bara förlita oss på ett index i tabellen, skulle vi behöva gå igenom ett indexträd med ett sökdjup på 21!
Uppenbarligen skulle själva vyn ge oss en prestandafördel (3x) jämfört med den enkla användningen av enbart indexet. Jag har försökt använda ett exempel från verkligheten, men du kommer att notera att en enkel lista över försäljning i Litauen skulle ge oss en ännu större fördel.
Observera att jag bara använder ett rakt b-träd för mitt exempel. Även om jag är ganska säker på att SQL Server använder någon variant av ett b-träd, vet jag inte detaljerna. Ändå gäller poängen.
Uppdatering 3: Frågan har kommit upp om en Indexerad vy bara använder ett index placerat på den underliggande tabellen. Det vill säga, för att parafrasera:"en indexerad vy är bara motsvarigheten till ett standardindex och den erbjuder inget nytt eller unikt för en vy." Om detta var sant, så skulle förstås ovanstående analys vara felaktig! Låt mig ge ett citat från Microsofts dokumentation som visar varför jag anser att denna kritik inte är giltig eller sann:
Att använda index för att förbättra frågeprestanda är inget nytt koncept; Men indexerade vyer ger ytterligare prestandafördelar som inte kan uppnås med standardindex.
Tillsammans med ovanstående citat angående beständigheten av data i fysisk lagring och annan information i dokumentationen om hur index skapas på Views, tror jag att det är säkert att säga att en Indexed View är inte bara en cachad SQL Select som råkar använda ett index definierat i huvudtabellen. Därför fortsätter jag att stå fast vid detta svar.