एसक्यूएल सर्वर जॉइन / ऑर्डर करने की प्रक्रिया


18

स्लो एसक्यूएल क्वेरी को पढ़ने के बाद , यह सुनिश्चित करने के लिए कि कैसे अनुकूलन करना है , यह मुझे प्रश्नों के सामान्य प्रदर्शन के बारे में सोच रहा था। निश्चित रूप से, हमें अपने प्रश्नों को सम्मिलित करने के लिए पहले तालिका (जब अन्य तालिकाएँ सम्मिलित होती हैं) के परिणामों की आवश्यकता होती है, ताकि हमारे प्रश्नों को सम्मिलित करने के लिए (इस प्रश्न के लिए आंतरिक जोड़) जितना संभव हो उतना छोटा हो।

उदाहरण, यह होना चाहिए:

SELECT *
FROM   ( SELECT * FROM table1 WHERE col = @val ) t
INNER JOIN table2 ON col = col2

इससे बेहतर / तेज़ हो:

SELECT *
FROM table1
INNER JOIN table2 ON col = col2
WHERE table1.col = @val

मेरा सिद्धांत इस प्रकार है (यह सही कार्यान्वयन नहीं हो सकता है, मैं एक SQL Server 2008 इंटर्नल बुक जिसे मैंने पढ़ा है (एमएसएफटी प्रेस) से याद रखने की कोशिश कर रहा हूं):

  1. क्वेरी प्रोसेसर को पहले बाईं तालिका (तालिका 1) मिलती है
  2. दूसरी तालिका (तालिका 2) से जुड़ता है और आवश्यक पंक्तियों (यदि लागू हो) को फ़िल्टर करने से पहले एक कार्टेशियन उत्पाद बनाता है।
  3. इसके बाद WHERE, ORDER BY, GROUP BY, HAVING क्लॉज़ स्टेटमेंट के साथ अंतिम प्रदर्शन करता है।

इसलिए यदि ऊपर दिए गए # 1 कथन में, तालिका छोटी है, तो कार्टेसियन उत्पादों को बनाते समय SQL इंजन को कम काम करना पड़ता है। फिर जब आप बयान में पहुंचते हैं, तो आपके पास एक कम परिणाम सेट होता है जिसमें से स्मृति में फ़िल्टर करना होता है।

मैं अभी तक यह असत्य है निशान से दूर हो सकता है। जैसा मैंने कहा, यह एक सिद्धांत है।

तुम्हारे विचार?

नोट : मैंने केवल इस प्रश्न के बारे में सोचा है और मुझे अभी तक किसी भी परीक्षण को चलाने का मौका नहीं मिला है।

नोट 2 : SQL सर्वर के रूप में टैग किया गया क्योंकि मुझे MySql आदि के कार्यान्वयन के बारे में कुछ भी पता नहीं है, कृपया किसी भी तरह से उत्तर देने / टिप्पणी करने के लिए स्वतंत्र महसूस करें

जवाबों:


15

किसी क्वेरी की तार्किक प्रक्रिया MSDN पर होती है (Microsoft SQL सर्वर टीम द्वारा लिखी जाती है, तृतीय पक्ष नहीं)

1. FROM
2. ON
3. JOIN
4. WHERE
5. GROUP BY
6. WITH CUBE or WITH ROLLUP
7. HAVING
8. SELECT
9. DISTINCT
10. ORDER BY
11. TOP

एक व्युत्पन्न तालिका इस प्रकार है, फिर बाहरी प्रश्न इसे फिर से करता है आदि आदि

हालांकि यह तर्कसंगत है: वास्तविक नहीं । कोई फर्क नहीं पड़ता कि SQL सर्वर वास्तव में कैसे करता है, ये शब्दार्थ पत्र को सम्मानित किया जाता है । "वास्तविक" क्वेरी ऑप्टिमाइज़र (QO) द्वारा निर्धारित किया जाता है और आपके द्वारा उल्लेखित मध्यवर्ती कार्टेसियन उत्पाद से बचते हैं।

यह ध्यान देने योग्य है कि एसक्यूएल घोषणात्मक है: आप कहते हैं कि "क्या" नहीं "कैसे" आप एक प्रक्रियात्मक / अनिवार्य प्रोग्रामिंग (जावा, .नेट) के लिए चाहेंगे। तो यह कहना कि "ऐसा पहले होता है" कई मामलों में गलत है (जैसे शॉर्ट सर्किट या एल-टू-आर WHERE के आदेश की धारणा)

उपरोक्त आपके मामले में, QO समान योजना को उत्पन्न नहीं करेगा चाहे वह कैसे संरचित हो क्योंकि यह एक सरल क्वेरी है।

हालाँकि, QO लागत आधारित है और एक जटिल प्रश्न के लिए आदर्श योजना को बनाने में 2 सप्ताह लग सकते हैं। तो यह "काफी अच्छा" करता है जो वास्तव में नहीं है।

तो आपका पहला मामला आशावादी को एक बेहतर योजना खोजने में मदद कर सकता है क्योंकि तार्किक प्रसंस्करण क्रम 2 प्रश्नों के लिए अलग है। लेकिन ऐसा नहीं हो सकता।

मैंने रिपोर्टिंग क्वेरी पर 60x गति प्रदर्शन सुधार प्राप्त करने के लिए SQL Server 2000 पर इस ट्रिक का उपयोग किया है। क्यूओ संस्करण को संस्करण में सुधार करता है क्योंकि यह इन चीजों को काम करने में बेहतर होता है।

और जिस पुस्तक का आपने उल्लेख किया है: उस पर कुछ विवाद है
तो एसओ और उसके बाद के लिंक देखें: /programming//q/3270338/27535


6

एक SQL क्वेरी प्रकृति में प्रक्रियात्मक नहीं है, इसमें शामिल ऑपरेटरों के नीचे से ऊपर प्रसंस्करण नहीं है। आपके उदाहरण के प्रश्नों में तालिकाओं के आदेश का निष्पादन योजना पर कोई प्रभाव नहीं पड़ता है क्योंकि वे तार्किक रूप से समतुल्य हैं और बिल्कुल उसी योजना को उत्पन्न करेंगे।

इस क्वेरी के लिए कोई योजना बनाते समय क्वेरी ऑप्टिमाइज़र विचार कर सकने वाले विकल्पों में से दो का मूल्यांकन करने की तरह है । प्राथमिक विकल्प जो योजना की पसंद को प्रभावित करता है, इसमें शामिल तालिकाओं के लिए आंकड़े और किसी भी उम्मीदवार योजनाओं में ऑपरेटर विकल्पों से जुड़ी लागतें हैं

एक बहुत ही सरल दो तालिकाएं शामिल हैं जैसे कि आपका उदाहरण सैकड़ों विभिन्न निष्पादन योजनाओं में से किसी एक से संतुष्ट हो सकता है। ऑप्टिमाइज़र तय करता है कि इन योजनाओं की लागतों की तुलना करके आपकी क्वेरी का जवाब देने का सबसे अच्छा तरीका क्या होगा।

यह कभी-कभी गलत हो जाता है और आप बेहतर अनुक्रमण के माध्यम से बेहतर विकल्प बनाने में मदद कर सकते हैं, आंकड़ों को अद्यतन रख सकते हैं और संकेत लगा सकते हैं। बहुत दुर्लभ मामलों में, आप फोर्स्ड आदेश संकेत का उपयोग करके निष्पादन के आदेश को लागू करना चाहते हैं, लेकिन इसे संयम से इस्तेमाल किया जाना चाहिए। यह नट को क्रैक करने के लिए एक हथौड़ा है, आशावादी आमतौर पर इसे बेहतर जानकारी खिलाकर बेहतर योजना बनाने में छेड़ा जा सकता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.