क्या यह सरल एसक्यूएल क्वेरी अनुकूलित किया जा सकता है?

Question

मैं निम्नलिखित प्रश्न हैं:

SELECT COUNT(*) 
FROM Address adr INNER JOIN 
    Audit a on adr.UniqueId = a.UniqueId 

• एक डेटाबेस पर (13 लाख पते, 4 मिलियन से अधिक आडिट)
• दोनों UniqueId कॉलम प्राथमिक कुंजी

क्वेरी है समूह है पूरा करने में काफी समय लग रहा है। मुझे गूंगा लगता है, लेकिन क्या इसे अनुकूलित करने का कोई तरीका है? मैं उन सभी पता प्रविष्टियों को गिनना चाहता हूं जिनमें अंतर्निहित ऑडिटेबल है।

संपादित: अपने सभी आदानों की बहुत सराहना कर रहे हैं, यहाँ कुछ और जानकारी कर रहे हैं:

• क्वेरी अक्सर (यह केवल मान्य है) नहीं चला जाएगा, लेकिन अनुक्रमित दृश्य टिप के लिए धन्यवाद, मैं निश्चित रूप से अपने ज्ञान में जोड़ दूंगा।
• सभी पते में 1 से 1 ऑडिट संबंधित है। सभी ऑडिट पते नहीं हैं।
• क्वेरी को समाप्त होने में 1 मिनट से अधिक समय लगता है। मुझे यह एक साधारण गिनती के लिए बहुत लंबा लगता है।

Answer 1

चूंकि आपके पास डेटा के दो सेट हैं, उसी मूल्य से आदेश दिया गया है .. क्या आपने नेस्टेड लूप में शामिल होने के बजाय विलय में शामिल होने का प्रयास किया है?

SET STATISTICS IO ON 
SET STATISTICS TIME ON 

SELECT COUNT(*) 
FROM Address adr INNER JOIN 
    Auditable a on adr.UniqueId = a.UniqueId 
OPTION (LOOP JOIN) 

SELECT COUNT(*) 
FROM Address adr INNER JOIN 
    Auditable a on adr.UniqueId = a.UniqueId 
OPTION (MERGE JOIN) 

SELECT COUNT(*) 
FROM Address adr INNER JOIN 
    Auditable a on adr.UniqueId = a.UniqueId 
OPTION (HASH JOIN) 

---

संपादित करें:

ये स्पष्टीकरण वैचारिक कर रहे हैं। SQL सर्वर मेरे उदाहरणों की तुलना में अधिक परिष्कृत परिचालन कर रहा है। यह वैचारिक समझ, एसईटी सांख्यिकी आदेशों के समय और तार्किक आईओ के माप से मेल खाती है, और क्वेरी निष्पादन योजनाओं की परीक्षा - मेरी क्वेरी ऑप्टिमाइज़िंग तकनीक (चार साल से अधिक उम्र के) का आधार बनती है। यह आपकी सेवा कर सकता है साथ ही यह मेरे पास है।

सेटअप

• ताश के पत्तों की 5 डेक प्राप्त करें।
• 1 डेक लें और एक मूल डेटा सेट तैयार करें।
• अन्य 4 डेक लें और बाल डेटा सेट का उत्पादन करें।
• कार्ड मूल्य द्वारा निर्धारित प्रत्येक डेटा को ऑर्डर करें।
• माता-पिता डेटा सेट में कार्ड की संख्या होने दें।
• बच्चे डेटा सेट में कार्ड की संख्या होने दें।

NestedLoop

• माता पिता डेटा सेट के ऊपर से एक कार्ड ले लो।
• मिलान के पहले अवसर के लिए सेट किए गए बाल डेटा सेट के भीतर खोजें (बाइनरी खोज का उपयोग करें)।
• गैर-मिलान मिलने तक पहले मैच से बाल डेटा सेट में आगे बढ़ें। अब आपको सभी मैच मिल गए हैं।
• पैरेंट डेटा सेट में प्रत्येक कार्ड के लिए इसे दोहराएं।

नेस्टेड लूप एल्गोरिथ्म दोहराता माता पिता डेटा सेट, और उसके बाद बच्चे डेटा हर माता-पिता के लिए एक बार सेट खोज करता है, यह लागत बनाने: मीटर * लॉग (एन)

मर्ज

• लें मूल डेटा सेट के शीर्ष से एक कार्ड।
• बाल डेटा सेट के शीर्ष से एक कार्ड लें।
• यदि कार्ड मिलते हैं, तो प्रत्येक डेक के शीर्ष से कार्ड खींचें जब तक प्रत्येक से एक गैर-मिलान नहीं मिलता है। माता-पिता और बाल मैचों के बीच प्रत्येक मिलान करने वाली जोड़ी बनाएं।
• यदि कार्ड मेल नहीं खाते हैं, तो माता-पिता और बाल कार्ड के बीच छोटे खोजें, और उस डेटा सेट के शीर्ष से एक कार्ड लें।

विलय में शामिल होने के बाद एल्गोरिदम एक बार माता-पिता डेटा सेट को पुन: स्थापित करता है और बच्चे डेटा एक बार सेट करता है, इसे लागत बनाते हैं: m + n। यह आदेश दिया जा रहा डेटा पर निर्भर करता है। यदि आप अन-आदेशित डेटा पर विलय में शामिल होने के लिए कहते हैं, तो आपको ऑर्डरिंग ऑपरेशन होगा! इससे लागत (एम * लॉग (एम)) + (एन * लॉग (एन)) + एम + एन है। यहां तक ​​कि कुछ मामलों में नेस्टेड लूप से भी बेहतर हो सकता है।

हैश

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

हैश एल्गोरिदम में शामिल होने के बाद माता-पिता डेटा सेट एक बार और बच्चे डेटा सेट एक बार फिर से सेट करता है, इसे लागत बनाते हैं: m + n। यह मूल डेटा सेट की संपूर्ण सामग्री को पकड़ने के लिए एक बड़ी पर्याप्त कार्ड तालिका रखने पर निर्भर करता है।

Answer 2

सुनिश्चित नहीं हैं कि अगर यह तेजी से होगा, लेकिन आप निम्नलिखित

SELECT COUNT(adr.UniqueID) FROM Address adr INNER JOIN Auditable a on adr.UniqueId = a.UniqueId 

यह आप एक ही गिनती देना चाहिए क्योंकि unqieieid अशक्त कभी नहीं होगा की कोशिश कर सकते।

Answer 3

ऑडिटेबल है। पता लगाने के लिए एक विदेशी कुंजी संदर्भ। यूनिकिड, जिसका अर्थ है ऑडिटेबल में कोई मूल्य नहीं है जो पता में मौजूद नहीं है?

यदि हां, तो यह काम कर सकते हैं और तेजी से हो सकता है:

SELECT COUNT(DISTINCT Auditable.UniqueID) 
FROM Auditable 

नोट: यह भी मानता है कि UniqueID पता तालिका में (/ प्राथमिक कुंजी), लेकिन लेखापरीक्षा योग्य तालिका में अद्वितीय नहीं अद्वितीय है

Answer 4

यदि आप अक्सर इस क्वेरी को चलाते हैं और इसे सुपर फास्ट होने की आवश्यकता है, तो इसके एक भौतिक अनुक्रमित दृश्य बनाएं। INSERT/UPDATE/DELETEs पर थोड़ा सा ओवरहेड होगा, लेकिन यह क्वेरी तुरंत तत्काल होगी। क्वेरी निष्पादन के दौरान महंगे गणनाओं को कम करने के लिए समेकन को प्रीकंप्यूटेड और इंडेक्स में संग्रहीत किया जा सकता है।

Improving Performance with SQL Server 2005 Indexed Views

Answer 5

विदेशी कुंजी पर सूचकांक गुम, मैं कहूंगा कि।

• 1.4 मिलियन और 4 मिलियन बड़ी टेबल नहीं हैं, वे छोटे हैं। कृपया 500 मिलियन प्रविष्टियों के माध्यम से बड़े होने पर कहें।

• एक वास्तविक उत्तर के लिए हमें निष्पादन योजना/क्वेरी योजना की आवश्यकता है, इसलिए हम देख सकते हैं कि क्या होता है।

• और यह जानना अच्छा होगा कि आपकी दुनिया में "लांग" क्या है (यह देखते हुए कि आपको लगता है कि 4 मिलियन पंक्तियां बहुत हैं)। यह प्रश्न कभी भी 1 सेकंड में जवाब नहीं देगा - तो आप क्या उम्मीद करते हैं और क्या होता है?

• मैं शर्त लगाता हूं, हालांकि, आपके पास एक अनुपलब्ध अनुक्रमणिका है। उस के शॉर्ट, मैं हार्डवेयर पर इशारा करना शुरू कर दूंगा (क्योंकि मैंने इसे भी देखा है, बकवास प्रदर्शन के कारण के रूप में)।

Answer 6

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

Answer 7

असली मुद्दा नेस्टेड लूप शामिल है। पता तालिका में प्रत्येक 1.4 मिलियन पंक्तियों के लिए आप एक इंडेक्स कर रहे हैं ऑडिटबल टेबल में खोजें। इसका मतलब है कि 1.4 एम रूट ब्लॉक, शाखा ब्लॉक, और लीफ ब्लॉक कुल 4.2 एम ब्लॉक पढ़ने के लिए पढ़ता है। पूरी अनुक्रमणिका शायद केवल 5 के ब्लॉक है या तो ... इसे एक हैश में शामिल होना चाहिए ताकि यह दोनों इंडेक्स को एक बार पढ़ सके, और उनके माध्यम से हो।

यदि आपको लगता है कि ये तालिकाएं बड़ी हैं, तो मुझे लगता है कि यह बहुत मेमोरी के बिना एक छोटे बॉक्स पर है। आपको यह सुनिश्चित करने की ज़रूरत है कि हैश को कुशलतापूर्वक शामिल करने के लिए पूरे इंडेक्स को स्मृति में फिट करने के लिए आवंटित पर्याप्त स्मृति है।

Answer 8

क्लॉज EXISTS INNER जॉइन की तुलना में चलाने के लिए कम महंगा है।

select COUNT(adr.UniqueId) 
    from Addresses adr 
    where EXISTS (
     select 1 
      from Auditables aud 
      where aud.UniqueId = adr.UniqueId 
    ) 

क्या यह आपकी आवश्यकता के अनुरूप है?

एनबी। डेटाबेस इंजन के लिए गाइड बहुत महंगा हैं।