Row_number . का उपयोग करके किसी क्वेरी से @@ rowcount प्राप्त करने का कुशल तरीका

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

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

अलग से चलाएँ `Count(*)`

एक अलग क्वेरी चलाएँ जो एक सरल "MyTable से गिनती (*) का चयन करें"
एक छोटी तालिका के लिए सरल और आसान
अनफ़िल्टर्ड बड़ी टेबल पर अच्छा है जो या तो संकीर्ण है या एक कॉम्पैक्ट गैर-क्लस्टर इंडेक्स है जिसका आप उपयोग कर सकते हैं
जब आपके पास एक जटिल WHERE/JOIN होता है तो टूट जाता है मानदंड क्योंकि चल रहा है WHERE/JOIN दोगुना महंगा है।
एक विस्तृत सूचकांक पर टूट जाता है क्योंकि पढ़ने की संख्या बढ़ जाती है।

गठबंधन `ROW_Number() OVER()` और `COUNT(1) OVER(PARTITION By 1)`

यह @RBarryYoung द्वारा सुझाया गया था। इसे लागू करने में सरल और बहुत लचीला होने का लाभ है।
नकारात्मक पक्ष यह है कि इसके बहुत से कारण हैं कि यह बहुत जल्दी महंगा हो सकता है।
उदाहरण के लिए, एक डीबी में मैं वर्तमान में काम कर रहा हूं, वहां लगभग 6000 पंक्तियों वाली एक मीडिया टेबल है। यह विशेष रूप से चौड़ा नहीं है, इसमें एक पूर्णांक क्लस्टर पीके और साथ ही एक कॉम्पैक्ट अद्वितीय अनुक्रमणिका है। फिर भी, एक साधारण COUNT(*) OVER(PARTITION BY 1) as TotalRows परिणाम ~ 12,000 पढ़ता है। इसकी तुलना एक साधारण SELECT COUNT(*) FROM Media . से करें - 12 पढ़ता है। वोज़र्स।

अस्थायी तालिकाएं / तालिका चर

ऐसी बहुत सारी रणनीतियाँ हैं जो परिणाम सेट लेती हैं और प्रासंगिक कुंजियों या परिणामों के खंडों को अस्थायी तालिकाओं / तालिका चर में सम्मिलित करती हैं।
छोटे/मध्यम आकार के परिणाम सेट के लिए यह शानदार परिणाम प्रदान कर सकता है।
इस प्रकार की रणनीति SQL के लगभग किसी भी प्लेटफॉर्म/संस्करण पर काम करती है।
परिणाम सेट पर कई बार काम करना (अक्सर एक आवश्यकता) भी आसान होता है।
बड़े परिणाम सेट के साथ काम करते समय नीचे की ओर है ... एक अस्थायी तालिका में कुछ मिलियन पंक्तियों को सम्मिलित करने की लागत होती है।
समस्या को कंपाउंड करना, TempDB पर उच्च वॉल्यूम सिस्टम दबाव में काफी कारक हो सकता है, और TempDB में अस्थायी तालिकाएँ प्रभावी रूप से काम कर रही हैं।

गाऊसी योग / दुहरी पंक्ति संख्या

यह विचार सबसेट पर निर्भर करता है गणितज्ञ गॉस ने कुछ का पता लगाया (संख्याओं की एक श्रृंखला का योग कैसे करें)। सबसेट यह है कि तालिका में किसी भी बिंदु से पंक्ति गणना कैसे प्राप्त करें।
संख्याओं की एक श्रृंखला से (Row_Number() ) 1 से N के लिए पंक्ति गणना (N + 1) - 1 . है . लिंक में अधिक स्पष्टीकरण।
सूत्र ऐसा प्रतीत होता है कि यह केवल N तक पहुंच जाएगा, लेकिन यदि आप सूत्र के साथ चिपके रहते हैं तो एक दिलचस्प चीजें होती हैं, आप तालिका के बीच में एक पृष्ठ से पंक्ति गणना का पता लगा सकते हैं।
शुद्ध परिणाम यह है कि आप ROW_Number() OVER(Order by ID) करते हैं और ROW_Number() OVER(Order by ID DESC) फिर दो संख्याओं का योग करें और 1 घटाएं।
एक उदाहरण के रूप में मेरी मीडिया तालिका का उपयोग करके मेरी पढ़ाई 12,000 से गिरकर लगभग 75 हो गई है।
एक बड़े पृष्ठ में आपने डेटा को कई बार दोहराया है, लेकिन रीड में ऑफ़सेट इसके लायक हो सकता है।
मैंने बहुत सारे परिदृश्यों पर इसका परीक्षण नहीं किया है, इसलिए यह अन्य परिदृश्यों में अलग हो सकता है।

शीर्ष (@n) / SET ROWCOUNT

ये विशिष्ट रणनीतियां नहीं हैं, लेकिन क्वेरी ऑप्टिमाइज़र के बारे में हम जो जानते हैं उसके आधार पर ऑप्टिमाइज़ेशन हैं।
शीर्ष(@n) [शीर्ष SQL 2008 में एक चर हो सकता है] या SET ROWCOUNT का रचनात्मक रूप से उपयोग करने से आपका कार्य सेट कम हो सकता है ... भले ही आप परिणाम सेट के मध्य पृष्ठ को खींच रहे हों, फिर भी आप परिणाम को सीमित कर सकते हैं
ये उपाय क्वेरी ऑप्टिमाइज़र व्यवहार के कारण काम करते हैं ... एक सर्विस पैक/हॉटफ़िक्स व्यवहार को बदल सकता है (हालाँकि शायद नहीं)।
प्रमाणिक उदाहरणों में SET ROWCOUNT थोड़ा सटीक हो सकता है
यह कार्यनीति पूरी पंक्ति गणना के लिए जिम्मेदार नहीं है, बस पेजिंग को और अधिक कुशल बनाती है

तो एक डेवलपर को क्या करना है?

मेरे अच्छे आदमी को पढ़ो, पढ़ो। यहां कुछ लेख दिए गए हैं जिन पर मैंने ध्यान दिया है...

क्यों हैं खिड़की वाले कुल कार्यों के लिए तार्किक पठन इतना अधिक है?

आशा है कि यह मदद करता है।