Para responder a su pregunta, debe desglosarse un poco:
SELECT * tiene 3 tipos principales de desventajas:
- Mantenimiento del código:el uso de SELECT * reduce la legibilidad de tablas/consultas complejas y puede causar problemas cuando una aplicación cliente espera un determinado resultado de una consulta, pero la tabla cambia
- Rendimiento de la red:el uso de SELECT * al devolver resultados a una aplicación cliente significa que todas las columnas se devolverán al cliente; si el cliente utiliza solo algunas de esas columnas, se desperdicia ancho de banda y la aplicación se ejecuta más lentamente de lo que podría.
- Indización/Rendimiento del plan de consulta:en algunas circunstancias, si tiene una consulta que realmente solo necesita devolver las columnas que participan en un índice, pero las devuelve todas en su lugar, podría obtener planes de consulta mucho peores creados por el motor.
No estoy seguro de lo que quiere decir con "implicación con respecto a la interpretación de comodines", pero sospecho que no comprende por qué SELECT * es una mala idea:el motor SQL valida las columnas proporcionadas de todos modos; el costo de "expandir" el comodín es esencialmente 0.
Un procedimiento almacenado no es realmente una "unidad de código compilada":el plan de consulta para un procedimiento almacenado generalmente se almacenará en caché después de que se ejecute por primera vez, pero lo mismo ocurre con las declaraciones SQL ad-hoc también en muchas/la mayoría de las circunstancias.
Ahora, para responder realmente a su pregunta:Sí , cualquier desventaja de usar SELECT * en SQL ad-hoc también se aplican, igualmente, a SQL dentro de un procedimiento almacenado.
