Изгледите в MySQL не се индексират, така че поради самото си естество изискват пълно сканиране при всеки достъп до тях. Най-общо казано, това прави Views наистина полезни само за ситуации, в които имате доста сложна статична заявка, която връща малък набор от резултати и планирате всеки път да вземете целия набор от резултати.
Редактиране: Разбира се, Views ще използва индексите на основните таблици, така че самият изглед да бъде оптимизиран (в противен случай те не биха имали никакъв смисъл да се използват), но тъй като няма индекси в изглед, не е възможно заявка WHERE на изгледът да бъде оптимизиран.
Изграждането на индекси за Views така или иначе би било скъпо, защото въпреки че не съм се опитвал да профилирам никакви Views, съм доста сигурен, че временна таблица се създава зад кулисите и след това се връща наборът от резултати. Вече отнема много време за конструирането на временната таблица, не бих искал изглед, който също се опитва да отгатне какви индекси са необходими. Което извежда втория момент, който е, че MySQL в момента не предлага метод за уточняване кои индекси да се използват за изглед, така че как знае кои полета трябва да бъдат индексирани? Предполага ли се въз основа на вашето запитване?
Може да помислите за използването на Временна таблица защото тогава можете да посочите индекси на полета във временната таблица. От опит обаче това е много, много бавно.
Ако всичко, което този изглед съдържа, е SELECT ALL FROM table1, table2, table3; тогава ще трябва да попитам защо тази заявка изобщо трябва да бъде в изглед? Ако по някаква причина е абсолютно необходимо, може да искате да използвате съхранена процедура, за да капсулирате заявката, тъй като тогава ще можете да получите оптимизирана производителност, като същевременно поддържате предимствата на по-просто извикване на базата данни за набора от резултати.
