SQL सर्वर मूल रूप से किसी भी . को निष्पादित करने के लिए इन चरणों से गुजरता है क्वेरी (संग्रहीत प्रक्रिया कॉल या तदर्थ SQL कथन):
1) वाक्यात्मक रूप से क्वेरी की जाँच करें
2) यदि यह ठीक है - यह यह देखने के लिए योजना कैश की जाँच करता है कि क्या उसके पास उस क्वेरी के लिए पहले से ही एक निष्पादन योजना है
3) यदि कोई निष्पादन योजना है - वह योजना है ( re-)उपयोग किया गया और क्वेरी निष्पादित की गई
4) यदि अभी तक कोई योजना नहीं है, तो एक निष्पादन योजना निर्धारित की जाती है
5) उस योजना को बाद में पुन:उपयोग के लिए योजना कैश में संग्रहीत किया जाता है
6) क्वेरी निष्पादित की जाती है
मुद्दा यह है:तदर्थ SQL और संग्रहीत कार्यविधियाँ व्यवहारिक रूप से अलग नहीं हैं .
यदि कोई एड-हॉक SQL क्वेरी पैरामीटर का ठीक से उपयोग कर रही है - जैसा कि वैसे भी, SQL इंजेक्शन हमलों को रोकने के लिए - इसकी प्रदर्शन विशेषताएँ अलग नहीं हैं और निश्चित रूप से कोई बदतर नहीं एक संग्रहीत कार्यविधि को क्रियान्वित करने की तुलना में।
संग्रहीत प्रक्रिया के अन्य लाभ हैं (उदाहरण के लिए, उपयोगकर्ताओं को सीधे टेबल एक्सेस देने की कोई आवश्यकता नहीं है), लेकिन प्रदर्शन के संदर्भ में, पैरामीट्रिज्ड एड-हॉक SQL क्वेरी का ठीक से उपयोग करना उतना ही कुशल है संग्रहीत कार्यविधियों का उपयोग करने के रूप में।
अपडेट करें: गैर-पैरामीट्रिज्ड . पर संग्रहीत कार्यविधियों का उपयोग करना क्वेरी दो मुख्य कारणों से बेहतर है:
-
चूंकि प्रत्येक गैर-पैरामीट्रिज्ड क्वेरी एक नई, भिन्न है SQL सर्वर से क्वेरी, इसे प्रत्येक क्वेरी के लिए निष्पादन योजना निर्धारित करने के सभी चरणों से गुजरना पड़ता है (इस प्रकार समय बर्बाद करना - और योजना कैश स्थान भी बर्बाद करना, क्योंकि निष्पादन योजना को योजना कैश में संग्रहीत करना वास्तव में अंत में मदद नहीं करता है , क्योंकि वह विशेष क्वेरी शायद नहीं . होगी फिर से निष्पादित किया जा सकता है)
-
गैर-पैरामीट्रिज्ड प्रश्नों से SQL इंजेक्शन हमले का खतरा होता है और उन्हें हर कीमत पर टाला जाना चाहिए
