Aby odpowiedzieć na twoje pytanie, należy je trochę rozebrać:
SELECT * ma 3 główne rodzaje wad:
- Obsługa kodu:użycie SELECT * zmniejsza czytelność złożonych tabel/zapytań i może powodować problemy, gdy aplikacja kliencka oczekuje określonego wyniku zapytania, ale tabela się zmienia
- Wydajność sieci:użycie SELECT * podczas zwracania wyników do aplikacji klienckiej oznacza, że wszystkie kolumny zostaną zwrócone do klienta; jeśli tylko niektóre z tych kolumn są używane przez klienta, wówczas przepustowość jest marnowana, a aplikacja działa wolniej niż mogłaby.
- Indeksowanie/wydajność planu zapytań:W pewnych okolicznościach, jeśli masz zapytanie, które naprawdę musi zwrócić tylko kolumny uczestniczące w indeksie, ale zamiast tego zwracasz je wszystkie, możesz uzyskać znacznie gorsze plany zapytań utworzone przez silnik.
Nie jestem pewien, co rozumiesz przez "implikację dotyczącą interpretacji symboli wieloznacznych", ale podejrzewam, że nie rozumiesz, dlaczego SELECT * to zły pomysł - silnik SQL i tak sprawdza poprawność dostarczonych kolumn; koszt „rozszerzenia” symbolu wieloznacznego wynosi zasadniczo 0.
Procedura składowana nie jest tak naprawdę „skompilowaną jednostką kodu”:plan zapytania dla procedury składowanej jest zwykle buforowany po pierwszym uruchomieniu, ale to samo dotyczy instrukcji SQL ad hoc również w wielu/większości przypadków.
Teraz, aby odpowiedzieć na Twoje pytanie:Tak , wszelkie wady używania SELECT * w ad-hoc SQL stosuje się również w równym stopniu do SQL wewnątrz procedury składowanej.
