यह उन चीजों में से एक है जो एक अजीब वक्र लगता है जहां जितना अधिक मैं इसके बारे में सोचता हूं, उतना ही यह समझ में आता है। निश्चित रूप से, कुछ हद तक। और फिर यह मुझे बिल्कुल समझ में नहीं आता है।पेजिंग इतनी संसाधन-महंगी क्यों है?
मुझे प्रबुद्ध करने के लिए देखभाल?
क्योंकि ज्यादातर मामलों में आपको अपने परिणामों को पहले क्रमबद्ध करना होगा। उदाहरण के लिए, जब आप Google पर खोज करते हैं, you can view only up to 100 pages of results। वे दिए गए कीवर्ड (या कीवर्ड के संयोजन) के लिए 1000 वेबसाइटों से परे पेज-रैंक द्वारा सॉर्टिंग को परेशान नहीं करते हैं।
अंकन तेज़ है। छंटनी धीमी है।
यह वास्तव में अस्पष्ट सवाल है। समस्या का बेहतर विचार पाने के लिए हमें एक ठोस उदाहरण की आवश्यकता होगी।
Lubos सही है, समस्या यह है कि आप पेजिंग कर रहे हैं (जो तार बंद डेटा की एक बड़ी राशि लेता है) नहीं है, लेकिन आप क्या वास्तव में पृष्ठ पर जा रहा है यह पता लगाने की जरूरत है कि ..
तथ्य यह है कि आपको पृष्ठ की आवश्यकता है, इसका तात्पर्य है कि बहुत सारे डेटा हैं। बहुत सारे डेटा को सॉर्ट करने में लंबा समय लगता है :)
मैंने सोचा कि आपका मतलब pagination of the printed page है - यही वह जगह है जहां मैंने अपने दांतों को काट दिया। मैं पृष्ठ के लिए सभी सामग्री एकत्र करने, स्थिति (यहां नियमों की एक बड़ी संख्या, कंस्ट्रेट इंजन काफी उपयोगी हैं) और औचित्य के बारे में एक महान मोनोलॉग दर्ज करने जा रहा था ... लेकिन स्पष्ट रूप से आप वेबपृष्ठों पर जानकारी व्यवस्थित करने की प्रक्रिया के बारे में बात कर रहे थे ।
इसके लिए, मुझे डेटाबेस हिट लगता है। डिस्क का उपयोग धीमा है। एक बार जब आप इसे स्मृति में प्राप्त कर लेते हैं, तो सॉर्टिंग सस्ता है।
बेशक एक यादृच्छिक क्वेरी पर सॉर्टिंग करने में कुछ समय लगता है, लेकिन यदि आपको समान पगने वाली क्वेरी के साथ समस्याएं नियामक उपयोग में समस्याएं आ रही हैं, तो डेटाबेस सेटअप के साथ कुछ गड़बड़ है (अनुचित रूप से अनुक्रमण/कोई भी नहीं, बहुत कम स्मृति आदि। मैं एक डीबी-मैनेजर नहीं हूं) या आप पेजिंग को गंभीरता से गलत कर रहे हैं:
बहुत गलत: उदाहरण के लिए select * from hugetable where somecondition; को सरणी के साथ पेज गिनती प्राप्त करने वाले सरणी में लेना। लम्बाई प्रासंगिक इंडेक्स चुनें और सरणी डाइक करें - फिर प्रत्येक पृष्ठ के लिए इसे दोहराएं ... यही वह है जिसे मैं गंभीर रूप से गलत कहता हूं।
बेहतर समाधान दो प्रश्न: केवल एक गिनती प्राप्त करने के बाद limit और offset का उपयोग करके परिणाम प्राप्त हो रहा है। (कुछ मालिकाना, गैर-मानक-एसक्यूएल सर्वर में एक प्रश्न विकल्प हो सकता है, मुझे पता नहीं है)
खराब समाधान वास्तव में छोटी तालिकाओं पर ठीक से काम कर सकता है (वास्तव में यह असंभव नहीं है कि यह बहुत छोटी तालिकाओं पर तेज़ है, क्योंकि दो प्रश्न बनाने का उपर एक प्रश्न में सभी पंक्तियों को प्राप्त करने से बड़ा है। मैं यह नहीं कह रहा हूं कि है ...) लेकिन जैसे ही डेटाबेस बढ़ने लगता है, समस्याएं स्पष्ट हो जाती हैं।
एक बड़े ऑफसेट के साथ LIMIT का संयोजन, और एक ऑर्डर बाय या ग्रुप बाय, अभी भी बहुत संसाधन गहन हो सकता है, यही कारण है कि Google को पूर्ण गिनती नहीं मिलती है (1000 से अधिक परिणाम और यह 'अनुमान' है) और न ही पेजिनेट पहले 1000 परिणामों से परे। – thomasrutter
यह सवाल बहुत अच्छी तरह से कवर किया गया लगता है, लेकिन के रूप में यह बहुत से लोगों को बाहर फैल जाती है मैं एक छोटे से कुछ MySQL विशिष्ट जोड़ देंगे:
बचें SQL_CALC_FOUND_ROWS का उपयोग कर। जब तक डेटासेट छोटा न हो, मैचों की गणना करना और दो अलग-अलग प्रश्नों में एक्स की मिलान राशि को पुनः प्राप्त करना बहुत तेज़ होगा। (यदि यह छोटा है, तो आप मुश्किल से किसी भी तरह का अंतर देखेंगे।)
रात्रिभोज के बाद एसओ के माध्यम से एक अनौपचारिक ब्राउज़, एक दिलचस्प टिप, 10 मिनट का परीक्षण और फिर 10 मिनट की ट्विक, और वॉयला, मेरा डेटाबेस लोड मेरी सबसे भारी साइट पर आ गया है! धन्यवाद! – jTresidder
यह एक अच्छी टिप है। किसी अन्य क्वेरी में गिनती करना पंक्ति डेटा लाने के बिना गिन सकता है और केवल इंडेक्स का उपयोग कर सकता है। हालांकि, क्या यह इनो डीबी में भी काम करता है क्योंकि यह मायआईसम में करता है? मुझे एक मजाकिया लग रहा है कि यह अलग है लेकिन गलत हो सकता है। – thomasrutter
यदि आप शीर्षक को देखते हैं तो प्रश्न समझ में आता है, जब आप स्वयं प्रश्न पढ़ते हैं तो यह समझ में आता है। –