नोट है कि यह एक विशिष्ट डीबीएमएस को विनियमित नहीं संग्रहित प्रक्रियाओं पर एक सामान्य लग रहे है। कुछ डीबीएमएस (और यहां तक कि, अलग-अलग समान डीबीएमएस के संस्करण!) इसके विपरीत काम कर सकते हैं, इसलिए आप यह सुनिश्चित करने से पहले अपने लक्ष्य डीबीएमएस से दोबारा जांच कर सकते हैं।
मैं लगभग एक दशक (सी, PHP, पीएल/एसक्यूएल, सी # .NET, और रूबी में अनुप्रयोग विकास के साथ) के साथ एक Sybase एएसई, MySQL, और SQL सर्वर डीबीए चालू और बंद किया गया है। इसलिए, मेरे पास इस (कभी-कभी) पवित्र युद्ध में पीसने के लिए कोई विशेष कुल्हाड़ी नहीं है।
- पूर्व पार्स एसक्यूएल
- पहले से बनाई गई क्वेरी निष्पादन योजना
- कम नेटवर्क:
संग्रहीत procs का ऐतिहासिक प्रदर्शन लाभ आम तौर पर निम्नलिखित (किसी विशेष क्रम में) से किया गया है विलंबता
संभावित कैश लाभ
प्री-पार्सड एसक्यूएल - बहुत ही सूक्ष्म स्तर को छोड़कर संकलित बनाम व्याख्या कोड के समान लाभ।
अभी भी एक फायदा है? आधुनिक सीपीयू पर बिल्कुल ध्यान देने योग्य नहीं है, लेकिन यदि आप एक एकल एसक्यूएल कथन भेज रहे हैं जो कि बहुत बड़ा ग्यारह-अरब गुना दूसरा है, तो पार्सिंग ओवरहेड जोड़ सकता है।
पहले से बनाई गई क्वेरी निष्पादन योजना। यदि आपके पास कई जॉइन हैं तो क्रमपरिवर्तन काफी अप्रबंधनीय हो सकता है (आधुनिक अनुकूलकों के प्रदर्शन कारणों से सीमाएं और कट ऑफ हैं)। यह बहुत ही जटिल एसक्यूएल के लिए अज्ञात नहीं है, मापने योग्य (मैंने एक जटिल क्वेरी को डीबीएमएस को ट्वीक करने से पहले एक योजना उत्पन्न करने के लिए 10+ सेकेंड लगते हैं) ऑप्टिमाइज़र के कारण "सर्वोत्तम सर्वोत्तम" " निष्पादन योजना। संग्रहित प्रक्रियाएं आम तौर पर इसे स्मृति में संग्रहीत करती हैं ताकि आप इस ओवरहेड से बच सकें।
अभी भी एक फायदा है? अधिकांश डीबीएमएस '(नवीनतम संस्करण) व्यक्तिगत SQL कथन के लिए क्वेरी की योजना कैश होगा, बहुत संग्रहीत procs और तदर्थ एसक्यूएल के प्रदर्शन के बीच अंतर को कम करने। कुछ चेतावनी और मामले हैं जिनमें यह मामला नहीं है, इसलिए आपको अपने लक्ष्य डीबीएमएस पर परीक्षण करने की आवश्यकता होगी।
इसके अलावा, अधिक से अधिक डीबीएमएस आप अनुकूलक पथ की योजना (सार क्वेरी की योजना) काफी अनुकूलन के समय को कम करने के लिए प्रदान करने की अनुमति (दोनों तदर्थ और संग्रहीत प्रक्रिया SQL के लिए !!)।
चेतावनी कैश्ड क्वेरी योजनाओं के लिए एक प्रदर्शन रामबाण नहीं हैं। कभी-कभी जेनरेट की गई क्वेरी योजना उप-इष्टतम है। उदाहरण के लिए, यदि आप SELECT * FROM table WHERE id BETWEEN 1 AND 99999999 भेजते हैं, तो डीबीएमएस इंडेक्स स्कैन के बजाय पूर्ण-तालिका स्कैन का चयन कर सकता है क्योंकि आप तालिका में प्रत्येक पंक्ति को पकड़ रहे हैं (इसलिए आंकड़े बताते हैं)। यदि यह कैश किया गया संस्करण है, तो आप बाद में प्रदर्शन प्राप्त कर सकते हैं जब आप बाद में SELECT * FROM table WHERE id BETWEEN 1 AND 2 भेजते हैं। http://www.microsoft.com/technet/prodtechnol/sql/2005/frcqupln.mspx और http://msdn.microsoft.com/en-us/library/ms181055.aspx और http://www.simple-talk.com/sql/performance/execution-plan-basics/
"संक्षेप में, वे निर्धारित किया है कि समान मूल्यों जब के अलावा और कुछ की आपूर्ति: इस के पीछे तर्क यह पोस्टिंग के दायरे से बाहर , लेकिन आगे पढ़ने के देखने के लिए है एक संकलन या रीकंपाइल का परिणाम ऑप्टिमाइज़र संकलन और कैशिंग उस विशेष मान के लिए क्वेरी प्लान का परिणाम हुआ। फिर भी, जब वह क्वेरी योजना बाद में पुन: उपयोग की गई के सामान्य मान ('एम', 'आर', या 'टी') के लिए समान क्वेरी के निष्पादन, इसके परिणामस्वरूप उप-इष्टतम प्रदर्शन हुआ। यह उप-इष्टतम प्रदर्शन समस्या क्वेरी तब तक मौजूद थी जब तक क्वेरी पुन: संकलित नहीं हुई थी। उस समय, @ P1 पैरामीटर मान आपूर्ति के आधार पर कम, क्वेरी या एक प्रदर्शन समस्या है नहीं हो सकता है हो सकता है। "
कम नेटवर्क विलंबता ए) आप पर एक ही एसक्यूएल चला रहे हैं और अधिक - और एसक्यूएल कोड के कई केबी तक जोड़ता है - इसे एक सरल "exec foobar" के साथ बदलकर वास्तव में जोड़ सकते हैं। बी) प्रक्रियात्मक कोड को डीबीएमएस में स्थानांतरित करने के लिए संग्रहीत प्रो का उपयोग किया जा सकता है। इससे बड़े पैमाने पर shuffling बचाता है क्लाइंट को केवल डेटा की मात्रा को वापस भेजने के लिए डेटा की मात्रा (या बिल्कुल भी नहीं!)। आपके कोड में डीबीएमएस बनाम में जॉइन करने के लिए एनालॉगस (हर किसी के पसंदीदा डब्ल्यूटीएफ!)
अभी भी एक फायदा है? ए) आधुनिक 1 जीबी (और 10 जीबी और ऊपर!) ईथरनेट वास्तव में यह नगण्य बनाते हैं। बी) इस बात पर निर्भर करता है कि आपके नेटवर्क को कितना संतृप्त किया गया है - किसी भी अच्छे कारण के लिए डेटा के कई मेगाबाइट्स को आगे क्यों नहीं फेंकते हैं?
संभावित कैश प्रदर्शन डेटा संभवतः हो सकता है की सर्वर साइड रूपांतरण लाभ तेजी से अगर आप डीबीएमएस पर पर्याप्त स्मृति और डेटा की जरूरत है सर्वर की स्मृति में है।
अभी भी एक फायदा है? जब तक आपके ऐप ने डीबीएमएस डेटा तक मेमोरी एक्सेस साझा नहीं की है, तो एज हमेशा प्रोसेस को संग्रहीत करेगा।
बेशक, संग्रहीत प्रक्रिया अनुकूलन की कोई चर्चा पैरामीटर और विज्ञापन एसक्यूएल की चर्चा के बिना पूरी हो जाएगी।
SELECT .. FROM yourtable WHERE foo = ? AND bar = ?
: एक मेजबान भाषा क्वेरी मूल्यों के लिए "पैरामीटर" का उपयोग करता है, उदाहरण के लिए में
Parameterized/तैयार एसक्यूएल
संग्रहित प्रक्रियाओं और तदर्थ एसक्यूएल के बीच एक क्रॉस की तरह, वे एम्बेडेड रहे हैं SQL कथन
ये एक प्रश्न का एक अधिक सामान्यीकृत संस्करण प्रदान करते हैं कि आधुनिक-दिन अनुकूलक क्वेरी निष्पादन योजना को कैश (और पुन: उपयोग) करने के लिए उपयोग कर सकते हैं, जिसके परिणामस्वरूप संग्रहित प्रक्रियाओं के प्रदर्शन लाभ का अधिकतर परिणाम होता है।
विज्ञापन एचक्यूएल बस अपने डीबीएमएस में एक कंसोल विंडो खोलें और एक SQL कथन टाइप करें।अतीत में, ये "सबसे खराब" कलाकार (औसतन) थे क्योंकि डीबीएमएस के पास पैरामीटर/संग्रहीत प्रो विधि में प्रश्नों को पूर्व-अनुकूलित करने का कोई तरीका नहीं था।
अभी भी एक नुकसान है? जरूरी नहीं है। अधिकांश डीबीएमएस में पैरामीटर संस्करणों में एसक्यूएल को "अमूर्त" करने की क्षमता होती है - इस प्रकार दोनों के बीच अंतर को कम या ज्यादा कम किया जाता है। कुछ इसे निहित रूप से करते हैं या कमांड सेटिंग (SQL सर्वर: http://msdn.microsoft.com/en-us/library/ms175037.aspx, ओरेकल: http://www.praetoriate.com/oracle_tips_cursor_sharing.htm) के साथ सक्षम होना चाहिए।
सबक सीखे? मूर का कानून जारी है और डीबीएमएस अनुकूलक, प्रत्येक रिलीज के साथ, अधिक परिष्कृत हो जाते हैं। निश्चित रूप से, आप संग्रहित प्रो के अंदर हर एक मूर्खतापूर्ण किशोर एसक्यूएल स्टेटमेंट रख सकते हैं, लेकिन सिर्फ यह पता है कि ऑप्टिमाइज़र पर काम कर रहे प्रोग्रामर बहुत स्मार्ट हैं और लगातार प्रदर्शन में सुधार के तरीकों की तलाश में हैं। आखिरकार (यदि यह पहले से यहां नहीं है) तो एसक्यूएल प्रदर्शन संग्रहीत प्रक्रिया प्रदर्शन से अलग-अलग (औसत पर!) बन जाएगा, इसलिए भारी संग्रहीत प्रक्रिया का उपयोग ** पूरी तरह से "प्रदर्शन कारणों" के लिए ** निश्चित रूप से समयपूर्व अनुकूलन की तरह लगता है मेरे लिए।
वैसे भी, मुझे लगता है कि यदि आप किनारे के मामलों से बचते हैं और काफी वेनिला एसक्यूएल है, तो आपको विज्ञापन और संग्रहित प्रक्रियाओं के बीच कोई अंतर नहीं दिखाई देगा।
मैट, यह संभवतः अब तक का सबसे अच्छा जवाब है जिसे मैंने एसओ पर पढ़ा है। बहुत बढ़िया! काश मैं आपको एक से अधिक बार रेट कर सकता हूं। – Danimal
यह एक महान प्रतिक्रिया है, लेकिन आपको ध्यान रखना चाहिए कि इसे * पैरामीटरकृत * एसक्यूएल - सादा वेनिला "प्रतिस्थापन के साथ एक विशाल स्ट्रिंग का निर्माण" होना चाहिए, एसक्यूएल भी प्रदर्शन नहीं करता है। –
@ जेफ एटवुड: अच्छा बिंदु; नग्न –