SQL Server gennemgår grundlæggende disse trin for at udføre enhver forespørgsel (opkald til lagret procedure eller ad-hoc SQL-sætning):
1) syntaktisk tjek forespørgslen
2) hvis den er i orden - den tjekker planens cache for at se, om den allerede har en eksekveringsplan for den forespørgsel
3) hvis der er en eksekveringsplan - den plan er ( gen-)bruges og forespørgslen udføres
4) hvis der ikke er nogen plan endnu, fastlægges en eksekveringsplan
5) denne plan gemmes i planens cache til senere genbrug
6) forespørgslen udføres
Pointen er:ad-hoc SQL og lagrede procedurer er ikke anderledes .
Hvis en ad-hoc SQL-forespørgsel bruger parametre korrekt - som den i hvert fald skal, for at forhindre SQL-injektionsangreb - er dens ydeevnekarakteristika ikke anderledes og absolut ikke værre end at udføre en lagret procedure.
Lagret procedure har andre fordele (det er ikke nødvendigt at give brugere direkte tabeladgang, for eksempel), men med hensyn til ydeevne er det lige så effektivt at bruge korrekt parametriserede ad-hoc SQL-forespørgsler som ved at bruge lagrede procedurer.
Opdatering: ved hjælp af lagrede procedurer over ikke-parametriserede forespørgsler er bedre af to hovedårsager:
-
da hver ikke-parametriseret forespørgsel er en ny, anderledes forespørgsel til SQL Server, skal den gennemgå alle trinene til at bestemme eksekveringsplanen for hver forespørgsel (og dermed spilde tid - og også spilde plancacheplads, da lagring af eksekveringsplanen i plancachen ikke hjælper i sidste ende , da den pågældende forespørgsel sandsynligvis ikke udføres igen)
-
ikke-parametriserede forespørgsler er i fare for SQL-injektionsangreb og bør undgås for enhver pris