Sqlserver
 sql >> डेटाबेस >  >> RDS >> Sqlserver

SQL सर्वर में गतिशील रूप से SQL बनाम पैरामीटर बनाया गया

मैं SQL इंजेक्शन तर्क को छोड़ दूँगा, जो कि बहुत प्रसिद्ध है और केवल पैरामीटर बनाम गैर-पैरामीटर के SQL पहलू पर ध्यान केंद्रित करता हूँ।

जब आप सर्वर, किसी भी बैच को SQL बैच भेजते हैं, तो उसे समझने के लिए उसे पार्स करना पड़ता है। किसी भी अन्य कंपाइलर की तरह, SQL कंपाइलर को एक AST तैयार करना होता है। टेक्स्ट से और फिर सिंटैक्स ट्री पर काम करें। अंततः ऑप्टिमाइज़र सिंटैक्स ट्री को एक निष्पादन ट्री में बदल देता है और अंत में एक निष्पादन योजना तैयार करता है और वह वास्तव में चलाया जाता है। लगभग 1995 के अंधेरे युग में यह फर्क पड़ता था कि बैच एक एड-हॉक क्वेरी या संग्रहीत प्रक्रिया थी, लेकिन आज यह बिल्कुल नहीं बनाता है, वे सभी समान हैं।

अब जहां पैरामीटर से फर्क पड़ता है वह यह है कि एक क्लाइंट जो क्वेरी भेजता है जैसे select * from table where primary_key = @pk भेजेगा बिल्कुल वही SQL पाठ हर बार, कोई फर्क नहीं पड़ता कि किस मूल्य में दिलचस्पी है। तब क्या होता है कि संपूर्ण ऊपर वर्णित प्रक्रिया शॉर्ट-सर्किट है। SQL स्मृति में अपरिष्कृत, पार्स न किए गए, पाठ . के लिए निष्पादन योजना की खोज करेगा इसे प्राप्त हुआ (इनपुट के हैश डाइजेस्ट के आधार पर) और, यदि पाया जाता है, तो उस योजना को क्रियान्वित करेगा। इसका मतलब है कि कोई पार्सिंग नहीं, कोई अनुकूलन नहीं, कुछ भी नहीं, बैच सीधे निष्पादन में जाता है . हर सेकंड सैकड़ों और हजारों छोटे अनुरोध चलाने वाले OLTP सिस्टम पर, यह तेज़ पथ प्रदर्शन में बहुत बड़ा अंतर लाता है।

यदि आप क्वेरी को फॉर्म में भेजते हैं select * from table where primary_key = 1 तो एसक्यूएल को कम से कम यह समझने के लिए इसे पार्स करना होगा कि टेक्स्ट के अंदर क्या है, क्योंकि टेक्स्ट संभवतः एक नया है, जो पिछले बैच से अलग है (यहां तक ​​​​कि एक भी वर्ण जैसे 1 बनाम 2 पूरे बैच को अलग बनाता है)। इसके बाद यह परिणामी सिंटैक्स ट्री पर काम करेगा और Simple Parameterisation<नामक प्रक्रिया का प्रयास करेगा। /ए> . यदि क्वेरी को ऑटो-पैरामीटराइज़ किया जा सकता है, तो SQL को अन्य प्रश्नों से इसके लिए कैश्ड निष्पादन योजना मिल सकती है जो पहले अन्य pk मानों के साथ चलती है और उस योजना का पुन:उपयोग करती है, इसलिए कम से कम आपकी क्वेरी को अनुकूलित करने की आवश्यकता नहीं है और आप छोड़ देते हैं एक वास्तविक निष्पादन योजना तैयार करने का चरण। लेकिन किसी भी तरह से आपने पूर्ण शॉर्ट-सर्किट प्राप्त नहीं किया, एक वास्तविक क्लाइंट पैरामीटरयुक्त क्वेरी के साथ प्राप्त होने वाला सबसे छोटा संभव पथ।

आप SQL सर्वर, SQL सांख्यिकी ऑब्जेक्ट में देख सकते हैं आपके सर्वर का प्रदर्शन काउंटर। काउंटर Auto-Param Attempts/sec प्रति सेकंड कई बार दिखाएगा एसक्यूएल को पैरामीटर के बिना प्राप्त क्वेरी को ऑटो-पैरामीटरयुक्त में अनुवाद करना है। प्रत्येक प्रयास से बचा जा सकता है यदि आप क्लाइंट में क्वेरी को ठीक से पैरामीटर करते हैं। यदि आपके पास Failed Auto-Params/sec की अधिक संख्या भी है इससे भी बदतर है, इसका मतलब है कि प्रश्न अनुकूलन और निष्पादन योजना निर्माण के पूरे चक्र में जा रहे हैं।



  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. ddmmyyyy एसक्यूएल में एसक्यूएल डेटाटाइम करने के लिए

  2. परिणाम के रूप में पूर्ण दिनांक-समय मान के साथ SQL सर्वर में प्रति घंटे पंक्तियों की गणना करें

  3. संग्रहीत प्रक्रिया में सम्मिलित \ हटाए गए तालिका का उपयोग कैसे करें?

  4. SQL सर्वर में एक दृश्य से SCHEMABINDING निकालें

  5. T-SQL का उपयोग करके लिंक किए गए सर्वर विकल्पों को कैसे संपादित करें