Pohledy v MySQL nejsou indexovány, takže ze své podstaty vyžadují úplné skenování při každém přístupu. Obecně řečeno, díky tomu jsou Views opravdu užitečné pouze v situacích, kdy máte poměrně složitý statický dotaz, který vrací malou sadu výsledků a plánujete pokaždé získat celou sadu výsledků.
Upravit: Views samozřejmě použijí indexy na podkladových tabulkách, aby byl samotný View optimalizován (jinak by nemělo smysl je používat), ale protože na View nejsou žádné indexy, není možné pro dotaz WHERE na zobrazení, které má být optimalizováno.
Vytváření indexů pro pohledy by bylo každopádně drahé, protože i když jsem se nepokoušel profilovat žádné pohledy, jsem si docela jistý, že v zákulisí se vytvoří dočasná tabulka a pak se vrátí výsledná sada. Sestavení dočasné tabulky už zabere spoustu času, nechtěl bych pohled, který se také snaží uhodnout, jaké indexy jsou potřeba. Což přináší druhý bod, který spočívá v tom, že MySQL v současné době nenabízí metodu, jak určit, jaké indexy použít pro zobrazení, takže jak ví, která pole je třeba indexovat? Odhaduje to na základě vašeho dotazu?
Můžete zvážit použití dočasné tabulky protože pak můžete zadat indexy pro pole v dočasné tabulce. Nicméně ze zkušenosti to bývá opravdu, ale opravdu pomalé.
Pokud vše toto zobrazení obsahuje, je SELECT ALL FROM tabulka1, tabulka2, tabulka3; pak bych se musel zeptat, proč musí být tento dotaz vůbec v pohledu? Pokud je to z nějakého důvodu nezbytně nutné, možná budete chtít k zapouzdření dotazu použít uloženou proceduru, protože pak budete moci získat optimalizovaný výkon při zachování výhody jednoduššího volání databáze pro sadu výsledků.