संभव डुप्लिकेट:
Performance of COUNT SQL functionगिनती (अनुक्रमित कॉलम) गिनती (*) से तेज है?
हाय सब, मैं बहुत बड़ी टेबल है और मैं एक में अभिलेखों की संख्या पता करने की जरूरत है, मेरा सवाल यह है कि यह रन के समय को कम करता है अगर मैं चलाएँ:
select count(indexed column like my PK) from tbTest
select count(*) from tbTest
सबसे अधिक संभावना है, यदि क्वेरी पूरी तालिका के बजाय इंडेक्स स्कैन करती है।
परीक्षण करने के लिए यह एक आसान बात है, अपने स्वयं के वैज्ञानिक बनें।
Performance of COUNT SQL function
महत्वपूर्ण बात यह देखने के नोट करने के लिए वे बराबर
दोनों समान हैं नहीं हैं। यदि आप दोनों के लिए क्वेरी निष्पादन योजना देखते हैं, तो दोनों "इंडेक्स स्कैन"
वे केवल समान हैं यदि चयनित कॉलम पीके है, क्योंकि COUNT (*) पीके इंडेक्स का उपयोग करेगा। –
हां! सवाल यह है कि अनुक्रमित पीके कॉलम! तो वे समान होना चाहिए! :) – Baaju
करेंगे क्योंकि सवाल यह है कि कोई प्रदर्शन अंतर है या नहीं, यह सूचकांक पर निर्भर करेगा। जब आप COUNT (*) करते हैं, तो यह पंक्तियों की संख्या निर्धारित करने के लिए पीके कॉलम का उपयोग करेगा। यदि आपके पास पीके कॉलम पर क्लस्टर्ड इंडेक्स के अलावा कोई इंडेक्स नहीं है, तो यह क्लस्टर इंडेक्स पर लीफ नोड्स को स्कैन करेगा। शायद यह बहुत सारे पेज हैं। यदि आपके पास क्लस्टर्ड इंडेक्स की तुलना में स्किनीयर नॉन क्लस्टर्ड इंडेक्स है, तो इसके बजाय यह चयन करेगा, जिसके परिणामस्वरूप कम पढ़ा जाएगा।
तो, यदि आपके द्वारा चुने गए कॉलम को तालिका पर सबसे छोटी संभव गैर-क्लस्टर इंडेक्स में निहित किया गया है, तो SQL क्वेरी ऑप्टिमाइज़र दोनों गिनती () के लिए चुन देगा (यदि आपके पास क्लस्टरर्ड ix है जो पीके है) और गिनती (indexed_column)। यदि आप एक गिनती (indexed_col) चुनते हैं जो केवल एक विस्तृत अनुक्रमणिका में निहित है, तो आपकी पीके क्लस्टर्ड इंडेक्स है तो गिनती () तेज होगी। इस काम का कारण यह है कि सभी गैर-क्लस्टर इंडेक्स में क्लस्टर इंडेक्स के लिए एक सूचक है और SQL सर्वर उस गैर-क्लस्टर इंडेक्स के आधार पर पंक्तियों की संख्या को समझ सकता है।
तो, सामान्य रूप से SQL सर्वर में, यह निर्भर करता है। एक शोप्लान करें और प्रश्नों की तुलना एक-दूसरे से करें।
दूसरे शब्दों में। सबसे अच्छा आप टैब से 'गिनती (अनुक्रमित नल कॉलम) के साथ एक ही गति प्राप्त कर सकते हैं और संभवतः बदतर। (जब तक आंकड़े बड़े पैमाने पर नहीं होते हैं।) और गिनती (*) के साथ क्वेरी ऑप्टिमाइज़र नई बेहतर इंडेक्स जोड़ने के मामले में अपनी योजना बदल सकता है। –
SELECT COUNT(*) तेज हो सकता है। ऐसा इसलिए है क्योंकि * का उपयोग करने के लिए किसी भी कॉलम को चुनने के लिए ऑप्टिमाइज़र स्वतंत्रता प्रदान करता है। मान लें कि आपके पास एक आईएनटी कॉलम पर प्राथमिक कुंजी है, और एक अलग क्लिनर्ड कुंजी पर एक अलग क्लिनर्ड कुंजी है। लेकिन प्राथमिक कुंजी क्लस्टर इंडेक्स की संभावना है, और इस तरह यह वास्तव में nonclustered bigint अनुक्रमणिका (अधिक पृष्ठों में) से काफी बड़ा है। इसलिए यदि अनुकूलक गैर-क्लस्टर इंडेक्स को चुनने के लिए स्वतंत्र है, तो यह प्रतिक्रिया को तेज़ी से वापस कर सकता है। तालिका के आधार पर संभावित अधिक तेज।
तो कुल मिलाकर इसे COUNT(*) के रूप में छोड़ना और ऑप्टिमाइज़र को चुनने देना हमेशा बेहतर होता है।
ईमानदार होने के लिए मुझे यह प्रश्न नहीं मिला लेकिन मुझे लगता है कि मेरा प्रश्न थोड़ा अलग है क्योंकि यह अनुक्रमित कॉलम के बारे में है: डी धन्यवाद – Asha