For at besvare dit spørgsmål skal det skilles lidt fra hinanden:
SELECT * har 3 hovedtyper af ulemper:
- Kodevedligeholdelse:Brug af SELECT * reducerer læsbarheden for komplekse tabeller/forespørgsler og kan forårsage problemer, når en klientapplikation forventer et bestemt resultat fra en forespørgsel, men tabellen ændres
- Netværksydelse:Brug af SELECT * ved returnering af resultater til en klientapplikation betyder, at alle kolonner returneres til klienten; hvis kun nogle af disse kolonner bruges af klienten, så er båndbredde spildt, og applikationen kører langsommere, end den kunne.
- Ydeevne for indeksering/forespørgselsplan:Under nogle omstændigheder, hvis du har en forespørgsel, der egentlig kun behøver at returnere de kolonner, der deltager i et indeks, men du returnerer dem alle i stedet for, kan du få meget dårligere forespørgselsplaner oprettet af motor.
Jeg er ikke sikker på, hvad du mener med "implikation vedrørende jokertegnsfortolkning", men jeg formoder, at du misforstår, hvorfor SELECT * er en dårlig idé - SQL-motoren validerer alligevel de angivne kolonner; omkostningerne ved at "udvide" jokertegnet er i det væsentlige 0.
En lagret procedure er egentlig ikke en "kompileret kodeenhed":forespørgselsplanen for en lagret procedure vil normalt blive cachelagret efter den første gang er kørt, men det samme gælder faktisk også for ad-hoc SQL-sætninger i mange/de fleste tilfælde.
For nu at svare på dit spørgsmål:Ja , eventuelle ulemper ved at bruge SELECT * i ad-hoc SQL gælder også SQL inde i en lagret procedure.