Widoki w MySQL nie są indeksowane, więc ze swej natury wymagają pełnego skanowania przy każdym dostępie. Ogólnie rzecz biorąc, sprawia to, że widoki są przydatne tylko w sytuacjach, w których masz dość złożone zapytanie statyczne, które zwraca mały zestaw wyników i za każdym razem planujesz pobrać cały zestaw wyników.
Edytuj: Oczywiście widoki będą używać indeksów w tabelach bazowych, aby sam widok był zoptymalizowany (w przeciwnym razie użycie ich nie miałoby żadnego sensu), ale ponieważ nie ma indeksów w widoku, nie jest możliwe zapytanie WHERE na Widok do optymalizacji.
Konstruowanie indeksów dla widoków i tak byłoby kosztowne, ponieważ chociaż nie próbowałem profilować żadnych widoków, jestem prawie pewien, że za kulisami tworzona jest tabela tymczasowa, a następnie zwracany jest zestaw wyników. Skonstruowanie tabeli tymczasowej zajmuje już dużo czasu, nie chciałbym widoku, który również próbuje odgadnąć, jakie indeksy są potrzebne. Co prowadzi do drugiej kwestii, która polega na tym, że MySQL nie oferuje obecnie metody określania indeksów, które mają być używane w widoku, więc skąd ma wiedzieć, które pola muszą być indeksowane? Czy to zgaduje na podstawie Twojego zapytania?
Możesz rozważyć użycie tabeli tymczasowej ponieważ wtedy można określić indeksy na polach w tabeli tymczasowej. Jednak z doświadczenia wynika, że jest to bardzo, bardzo powolne.
Jeśli wszystko, co zawiera ten widok, to SELECT ALL FROM table1, table2, table3; to musiałbym zapytać, dlaczego to zapytanie w ogóle musi być w widoku? Jeśli z jakiegoś powodu jest to absolutnie konieczne, możesz chcieć użyć procedury składowanej do enkapsulacji zapytania, ponieważ wtedy będziesz w stanie uzyskać zoptymalizowaną wydajność, zachowując jednocześnie korzyść prostszego wywołania bazy danych dla zbioru wyników.
