SQL Server doorloopt in principe deze stappen om elke . uit te voeren query (opgeslagen procedure-aanroep of ad-hoc SQL-instructie):
1) syntactisch de query controleren
2) als het in orde is - het controleert de plancache om te zien of het al een uitvoeringsplan voor die query heeft
3) als er een uitvoeringsplan is - dat plan is ( hergebruikt en de query uitgevoerd
4) als er nog geen plan is, wordt een uitvoeringsplan bepaald
5) dat plan wordt opgeslagen in de plancache voor later hergebruik
6) de zoekopdracht wordt uitgevoerd
Het punt is:ad-hoc SQL en opgeslagen procedures zijn in principe niet anders .
Als een ad-hoc SQL-query parameters correct gebruikt - zoals het sowieso zou moeten om SQL-injectie-aanvallen te voorkomen - zijn de prestatiekenmerken niet anders en zeker niet slechter dan het uitvoeren van een opgeslagen procedure.
Opgeslagen procedures hebben andere voordelen (u hoeft gebruikers bijvoorbeeld geen directe toegang tot de tabel te verlenen), maar in termen van prestaties is het gebruik van correct geparametriseerde ad-hoc SQL-query's net zo efficiënt zoals het gebruik van opgeslagen procedures.
Bijwerken: met behulp van opgeslagen procedures over niet-geparametriseerde zoekopdrachten zijn om twee hoofdredenen beter:
-
aangezien elke niet-geparametriseerde zoekopdracht een nieuwe, andere . is query naar SQL Server, het moet alle stappen doorlopen om het uitvoeringsplan te bepalen, voor elke query (en dus tijdverspilling - en ook verspilling van plancacheruimte, aangezien het opslaan van het uitvoeringsplan in de plancache uiteindelijk niet echt helpt , aangezien die specifieke zoekopdracht waarschijnlijk niet . zal zijn opnieuw worden uitgevoerd)
-
niet-geparametreerde zoekopdrachten lopen het risico van een SQL-injectieaanval en moeten koste wat kost worden vermeden