Visninger i MySQL er ikke indekseret, så i sagens natur kræver det en fuld scanning, hver gang de tilgås. Generelt gør dette Views kun nyttige i situationer, hvor du har en ret kompleks statisk forespørgsel, der returnerer et lille resultatsæt, og du planlægger at få fat i hele resultatsættet hver gang.
Rediger: Selvfølgelig vil Views bruge indekserne på de underliggende tabeller, så selve View er optimeret (ellers ville de slet ikke give nogen mening at bruge), men fordi der ikke er nogen indekser på en View, er det ikke muligt at foretage en WHERE-forespørgsel på visningen, der skal optimeres.
Det ville alligevel være dyrt at konstruere indekser til visninger, for selvom jeg ikke har forsøgt at profilere nogen visninger, er jeg ret sikker på, at der er konstrueret en midlertidig tabel bag kulisserne, og så returneres resultatsættet. Det tager allerede masser af tid at konstruere temp-tabellen, jeg ville ikke have en visning, der også forsøger at gætte, hvilke indekser der er nødvendige. Hvilket bringer det andet punkt frem, som er, at MySQL i øjeblikket ikke tilbyder en metode til at specificere, hvilke indekser der skal bruges til en visning, så hvordan ved den, hvilke felter der skal indekseres? Gætter det baseret på din forespørgsel?
Du kan overveje at bruge en midlertidig tabel fordi så kan du angive indekser på felter i den midlertidige tabel. Men erfaringsmæssigt har dette en tendens til at være virkelig, virkelig langsomt.
Hvis alt denne visning indeholder, er en VÆLG ALLE FRA tabel1, tabel2, tabel3; så bliver jeg nødt til at spørge, hvorfor denne forespørgsel overhovedet skal være i en visning? Hvis det af en eller anden grund er absolut nødvendigt, vil du måske bruge en lagret procedure til at indkapsle forespørgslen, da du så vil være i stand til at få optimeret ydeevne og samtidig bevare fordelen ved et enklere kald til databasen for resultatsættet.