Да , изгледи могат имат присвоен клъстериран индекс и когато го направят, те ще съхраняват временни резултати, които могат да ускорят получените заявки.
Собствената документация на Microsoft показва много ясно, че Views могат да подобрят производителността.
Първо, повечето изгледи, които хората създават, са прости изгледи и не използват тази функция и следователно не се различават от директното запитване на базовите таблици. Простите изгледи са разширени на място и така не допринасят пряко за подобрения на производителността - това е вярно. Въпреки това, индексираните изгледи могат драматично подобряване на производителността.
Нека отида директно към документацията:
След като в изгледа се създаде уникален клъстериран индекс, наборът от резултати на изгледа се материализира незабавно и се запазва във физическо съхранение в базата данни, спестявайки режийните разходи за извършване на тази скъпа операция по време на изпълнение.
Второ, тези индексирани изгледи могат да работят дори когато не са пряко посочени от друга заявка тъй като оптимизаторът ще ги използва вместо препратка към таблица, когато е подходящо.
Отново, документацията:
Индексираният изглед може да се използва при изпълнение на заявка по два начина. Заявката може да препраща директно към индексирания изглед или, което е по-важно, оптимизаторът на заявки може да избере изгледа, ако определи, че изгледът може да бъде заменен за част или цялата заявка в плана за заявка с най-ниска цена. Във втория случай, индексираният изглед се използва вместо основните таблици и техните обикновени индекси. Не е необходимо изгледът да бъде посочен в заявката, за да може оптимизаторът на заявки да го използва по време на изпълнение на заявката. Това позволява на съществуващите приложения да се възползват от новосъздадените индексирани изгледи, без да променят тези приложения.
Тази документация, както и диаграми, демонстриращи подобрения в производителността, можете да намерите тук.
Актуализация 2: отговорът е критикуван на базата на това, че именно „индексът“ осигурява предимството на производителността, а не „Изгледът“. Това обаче лесно се опровергава.
Да кажем, че сме софтуерна компания в малка държава; Ще използвам Литва за пример. Ние продаваме софтуер по целия свят и съхраняваме нашите записи в база данни на SQL Server. Ние сме много успешни и така за няколко години имаме над 1 000 000 записа. Въпреки това често се налага да отчитаме продажби за данъчни цели и откриваме, че сме продали само 100 копия на нашия софтуер в нашата страна. Чрез създаване на индексиран изглед само на литовските записи, ние получаваме да съхраняваме необходимите ни записи в индексиран кеш, както е описано в документацията на MS. Когато стартираме нашите отчети за продажбите в Литва през 2008 г., нашата заявка ще търси в индекс с дълбочина само 7 (Log2(100) с някои неизползвани листа). Ако трябваше да направим същото без VIEW и просто разчитайки на индекс в таблицата, ще трябва да преминем през индексно дърво с дълбочина на търсене 21!
Ясно е, че самият View ще ни осигури предимство на производителността (3x) пред простото използване само на индекса. Опитах се да използвам пример от реалния свят, но ще забележите, че прост списък с продажби в Литва би ни дал още по-голямо предимство.
Обърнете внимание, че използвам само право b-дърво за моя пример. Въпреки че съм доста сигурен, че SQL Server използва някакъв вариант на b-дърво, не знам подробностите. Независимо от това, въпросът е валиден.
Актуализация 3: Възникна въпросът дали един индексиран изглед просто използва индекс, поставен върху основната таблица. Тоест, ако перифразираме:„индексираният изглед е просто еквивалент на стандартен индекс и не предлага нищо ново или уникално за един изглед“. Ако това беше вярно, разбира се, тогава горният анализ би бил неправилен! Позволете ми да предоставя цитат от документацията на Microsoft, който демонстрира защо смятам, че тази критика не е валидна или вярна:
Използването на индекси за подобряване на производителността на заявките не е нова концепция; индексираните изгледи обаче осигуряват допълнителни ползи за производителността, които не могат да бъдат постигнати с помощта на стандартни индекси.
Заедно с горния цитат относно запазването на данните във физическото съхранение и друга информация в документацията за това как се създават индекси в Views, мисля, че е безопасно да се каже, че индексиран изглед е не просто кеширан SQL Select, който използва индекс, дефиниран в главната таблица. Затова продължавам да стоя зад този отговор.
