Per rispondere alla tua domanda, è necessario smontarlo un po':
SELECT * presenta 3 tipi principali di svantaggi:
- Manutenzione del codice:l'utilizzo di SELECT * riduce la leggibilità per tabelle/query complesse e può causare problemi quando un'applicazione client si aspetta un determinato risultato da una query, ma la tabella cambia
- Prestazioni di rete:l'utilizzo di SELECT * quando si restituiscono risultati a un'applicazione client significa che tutte le colonne verranno restituite al client; se solo alcune di queste colonne vengono utilizzate dal client, la larghezza di banda viene sprecata e l'applicazione viene eseguita più lentamente di quanto potrebbe.
- Indicizzazione/Prestazioni del piano di query:in alcune circostanze, se si dispone di una query che deve davvero restituire solo le colonne che fanno parte di un indice, ma invece le restituisci tutte, potresti ottenere piani di query molto peggiori creati dal motore.
Non sono sicuro di cosa intendi per "implicazione relativa all'interpretazione dei caratteri jolly", ma sospetto che tu stia fraintendendo perché SELECT * è una cattiva idea:il motore SQL convalida comunque le colonne fornite; il costo di "espansione" del carattere jolly è essenzialmente 0.
Una stored procedure non è in realtà una "unità di codice compilata":il piano di query per una stored procedure viene solitamente memorizzato nella cache dopo la prima esecuzione, ma lo stesso vale per le istruzioni SQL ad hoc anche in molte/molte circostanze.
Ora, per rispondere effettivamente alla tua domanda:Sì , eventuali svantaggi dell'utilizzo di SELECT * in SQL ad hoc si applicano, allo stesso modo, anche a SQL all'interno di una stored procedure.
