Weergaven in MySQL worden niet geïndexeerd, dus door hun aard vereisen ze elke keer dat ze worden geopend een volledige scan. Over het algemeen maakt dit Views eigenlijk alleen nuttig voor situaties waarin je een vrij complexe statische query hebt die een kleine resultatenset retourneert en je van plan bent om elke keer de volledige resultatenset te pakken.
Bewerken: Natuurlijk zal Views de indexen op de onderliggende tabellen gebruiken zodat de View zelf geoptimaliseerd wordt (anders zouden ze geen enkele zin hebben om te gebruiken) maar omdat er geen indexen zijn op een View is het niet mogelijk om een WHERE-query op de te optimaliseren weergave.
Het maken van indexen voor Views zou hoe dan ook duur zijn, want hoewel ik niet heb geprobeerd om Views te profileren, ben ik er vrij zeker van dat er achter de schermen een tijdelijke tabel wordt gemaakt en dat vervolgens de resultatenset wordt geretourneerd. Het kost al veel tijd om de tijdelijke tabel te maken, ik zou geen weergave willen die ook probeert te raden welke indexen nodig zijn. Dat brengt het tweede punt naar voren, namelijk dat MySQL momenteel geen methode biedt om te specificeren welke indexen moeten worden gebruikt voor een weergave, dus hoe weet het welke velden moeten worden geïndexeerd? Klopt het op basis van uw zoekopdracht?
U kunt overwegen een tijdelijke tabel te gebruiken want dan kun je indexen specificeren op velden in de tijdelijke tabel. Echter, uit ervaring is dit vaak erg, erg traag.
Als al deze weergave een SELECT ALL FROM bevat table1, table2, table3; dan zou ik moeten vragen waarom deze vraag überhaupt in een View moet staan? Als het om de een of andere reden absoluut noodzakelijk is, wil je misschien een opgeslagen procedure gebruiken om de query in te kapselen, omdat je dan geoptimaliseerde prestaties kunt krijgen terwijl je het voordeel behoudt van een eenvoudigere aanroep van de database voor de resultatenset.