ऑफ़सेट सीमा वाली क्वेरी का चयन बहुत धीमा है

यह धीमा है क्योंकि इसे शीर्ष offset का पता लगाने की आवश्यकता है पंक्तियों और अगले 100 को स्कैन करें। जब आप भारी ऑफसेट से निपट रहे हों तो अनुकूलन की कोई मात्रा नहीं बदलेगी।

ऐसा इसलिए है क्योंकि आपकी क्वेरी का शाब्दिक अर्थ निर्देश है DB इंजन offset 3900000 . का उपयोग करके बहुत सारी पंक्तियों को देखने के लिए - वह 3.9M पंक्तियाँ हैं। इसे कुछ हद तक तेज करने के विकल्प बहुत अधिक नहीं हैं।

सुपर-फास्ट रैम, एसएसडी आदि मदद करेंगे। लेकिन ऐसा करने से आपको केवल एक स्थिर कारक से ही लाभ होगा, जिसका अर्थ है कि जब तक आप पर्याप्त मात्रा में ऑफसेट तक नहीं पहुंच जाते, तब तक यह कैन को नीचे गिरा रहा है।

यह सुनिश्चित करना कि तालिका स्मृति में फिट बैठती है, बहुत अधिक अतिरिक्त होने से भी पहली बार को छोड़कर एक बड़े स्थिर कारक से मदद मिलेगी। लेकिन यह एक बड़ी पर्याप्त तालिका या अनुक्रमणिका के साथ संभव नहीं हो सकता है।

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

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

जैसा कि उम्मीद से अधिक स्पष्ट है, कोई वास्तविक जादू की गोली नहीं है जब आप इस बड़े ऑफसेट के साथ काम कर रहे हों। वैकल्पिक तरीकों को देखना अक्सर बेहतर होता है।

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

इसके बजाय कोई दूसरा तरीका लगाएं:

example.com?page_number=[huge]

कुछ ऐसा करें:

example.com?page_following=[huge]

इस तरह, आप इस बात का पता लगाते हैं कि आप अपनी अनुक्रमणिका में कहाँ हैं, और क्वेरी बहुत तेज़ हो जाती है क्योंकि यह एक गजियन पंक्तियों के माध्यम से जुताई के बिना सीधे सही प्रारंभिक बिंदु पर जा सकती है:

select * from foo where ID > [huge] order by ID limit 100

स्वाभाविक रूप से, आप कूदने की क्षमता खो देते हैं उदा। पृष्ठ 3000। लेकिन इसे कुछ ईमानदार विचार दें:पिछली बार जब आप किसी साइट के मासिक संग्रह के लिए सीधे जाने या उसके खोज बॉक्स का उपयोग करने के बजाय एक विशाल पृष्ठ संख्या पर कूद गए थे?

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