इंडेक्स लुकअप मान . के अनुसार होते हैं , स्थिति . द्वारा नहीं . एक अनुक्रमणिका 2955900 मान की खोज कर सकती है, लेकिन आप उसके लिए नहीं पूछ रहे हैं। आप क्वेरी को तालिका में 2955900वीं पंक्ति के ऑफ़सेट से प्रारंभ करने के लिए कह रहे हैं।
अनुकूलक यह नहीं मान सकता कि सभी प्राथमिक कुंजी मान क्रमागत हैं। तो बहुत संभव है कि 2955900वीं पंक्ति का मान उससे कहीं अधिक हो।
यहां तक कि अगर प्राथमिक कुंजी मान लगातार हैं, तो आपके पास WHERE शर्त हो सकती है जो केवल मेल खाती है, उदाहरण के लिए, 45% पंक्तियां। इस मामले में 2955900 वीं पंक्ति पर आईडी मान रास्ता . होगा आईडी मान 2955900 से आगे।
दूसरे शब्दों में, आईडी मान 2955900 का इंडेक्स लुकअप 2955900वीं पंक्ति डिलीवर नहीं करेगा।
तो MySQL एक सीमा के ऑफसेट के लिए अनुक्रमणिका का उपयोग नहीं कर सकता है। यह होना चाहिए पंक्तियों को तब तक गिनने के लिए स्कैन करें जब तक कि वह ऑफ़सेट+सीमा पंक्तियों तक न पहुँच जाए।
MySQL में LIMIT से संबंधित अनुकूलन हैं। , लेकिन यह एक बार टेबल-स्कैन को रोकने के बारे में अधिक है जब यह वापस आने के लिए पंक्तियों की संख्या तक पहुंच गया है। अनुकूलक अभी भी किसी EXPLAIN योजना में रिपोर्ट कर सकता है कि यह अपेक्षा करता है कि यह हो सकता है पूरी तालिका को स्कैन करना होगा।
FORCE INDEX के बारे में बार-बार गलतफहमी यह है कि यह एक सूचकांक के उपयोग को बाध्य करता है। :-)वास्तव में, यदि क्वेरी नहीं एक अनुक्रमणिका का उपयोग करें (या यदि उपलब्ध अनुक्रमणिका का इस क्वेरी के लिए कोई लाभ नहीं है), तो FORCE INDEX का कोई प्रभाव नहीं पड़ता है।
अपनी टिप्पणी दें:
पेजिनेशन डेटा-संचालित वेब अनुप्रयोगों का लगातार अभिशाप है। यह सुविधा कितनी सामान्य है, इसके बावजूद इसे ऑप्टिमाइज़ करना आसान नहीं है। यहां कुछ युक्तियां दी गई हैं:
-
आप ऑफ़सेट 2955900 के साथ क्वेरी क्यों कर रहे हैं? क्या आप वास्तव में उम्मीद करते हैं कि उपयोगकर्ता इतने सारे पृष्ठों को छान लेंगे? अधिकांश उपयोगकर्ता कुछ पृष्ठों के बाद छोड़ देते हैं (वास्तव में कितने एप्लिकेशन के प्रकार और डेटा पर निर्भर करते हैं)।
-
प्रश्नों की संख्या कम करें। आपका पेजिनेशन फ़ंक्शन पहले 5-10 पेज ला सकता है, भले ही वह उपयोगकर्ता को पहला पेज ही दिखाता हो। अन्य पृष्ठों को कैश करें, इस धारणा के साथ कि उपयोगकर्ता कुछ पृष्ठों के माध्यम से आगे बढ़ेगा। केवल अगर वे पृष्ठों के कैश्ड सेट से आगे बढ़ते हैं तो क्या आपके ऐप को एक और क्वेरी करनी होगी। आप क्लाइंट के ब्राउज़र पर Javascript के सभी 10 पृष्ठों को कैश भी कर सकते हैं, इसलिए "अगला" पर क्लिक करना तात्कालिक है उनके लिए (कम से कम उन पहले कुछ पन्नों के लिए)।
-
किसी भी यूजर इंटरफेस पर "लास्ट" बटन न लगाएं, क्योंकि लोग इसे उत्सुकता से क्लिक करेंगे। ध्यान दें कि Google के पास "अगला" बटन है, लेकिन "अंतिम" बटन नहीं है। इसलिए UI ही लोगों को उच्च ऑफ़सेट के साथ अक्षम क्वेरी चलाने से हतोत्साहित करता है।
-
यदि उपयोगकर्ता एक समय में एक पृष्ठ को आगे बढ़ा रहा है, तो अगले पृष्ठ की क्वेरी के WHERE खंड में पिछले पृष्ठ में लौटाए गए उच्चतम आईडी मान का उपयोग करें। अर्थात। निम्नलिखित करता है बिना किसी FORCE INDEX संकेत के भी अनुक्रमणिका का उपयोग करें:
SELECT * FROM thistable WHERE id > 544 LIMIT 20
