Vyer i MySQL är inte indexerade så till sin natur kräver en fullständig genomsökning varje gång de nås. Generellt sett gör detta Views egentligen bara användbara för situationer där du har en ganska komplex statisk fråga som returnerar en liten resultatuppsättning och du planerar att ta hela resultatuppsättningen varje gång.
Redigera: Naturligtvis kommer Views att använda indexen på de underliggande tabellerna så att själva vyn är optimerad (annars skulle de inte vara meningsfulla alls att använda) men eftersom det inte finns några index på en vy är det inte möjligt för en WHERE-fråga på vyn som ska optimeras.
Att konstruera index för Views skulle vara dyrt ändå, för även om jag inte har försökt profilera några Views, är jag ganska säker på att en temporär tabell är konstruerad bakom kulisserna och sedan returnerade resultatuppsättningen. Det tar redan gott om tid att konstruera temptabellen, jag skulle inte vilja ha en vy som också försöker gissa vilka index som behövs. Vilket tar upp den andra punkten som är att MySQL för närvarande inte erbjuder en metod för att specificera vilka index som ska användas för en vy, så hur vet den vilka fält som behöver indexeras? Gissar det baserat på din fråga?
Du kan överväga att använda en Tillfällig tabell för då kan du ange index på fält i den temporära tabellen. Men av erfarenhet tenderar detta att gå riktigt, riktigt långsamt.
Om allt som denna vy innehåller är en VÄLJ ALLA FRÅN tabell1, tabell2, tabell3; då måste jag fråga varför den här frågan överhuvudtaget måste finnas i en vy? Om det av någon anledning är absolut nödvändigt, kanske du vill använda en lagrad procedur för att kapsla in frågan eftersom du då kommer att kunna få optimerad prestanda samtidigt som du behåller fördelen med ett enklare anrop till databasen för resultatuppsättningen.