पेजिंग के साथ बड़ी संख्या में डेटाबेस प्रविष्टियों को संसाधित करना समय के साथ धीमा हो जाता है

यहाँ मैंने जो किया है, और कुल निष्पादन समय को 10 के कारक से कम कर दिया है।

मैंने अपनी मूल क्वेरी की निष्पादन योजना के रूप में जो महसूस किया वह यह था कि यह सभी परिणामों को क्रमबद्ध करने और अनुक्रमणिका को अनदेखा करने के लिए फाइलोर्ट का उपयोग कर रहा था। यह थोड़ा बेकार है।

मेरा परीक्षण डेटाबेस:5 एम रिकॉर्ड, 20 जीबी आकार। तालिका संरचना प्रश्न के समान है

पहली क्वेरी में सीधे blobCol प्राप्त करने के बजाय, मुझे पहले प्रत्येक पृष्ठ की शुरुआत के लिए 'नाम' का मान मिलता है। इस क्वेरी को अनिश्चित काल तक चलाएं जब तक कि यह 0 परिणाम न दे। हर बार, परिणाम को सूची में जोड़ें

SELECT name
FROM my_table
where id = <anyId> // I use the id column for partitioning so I need this here
order by name
limit <pageSize * pageNumber>, 1

साइन पेज नंबर पहले से ज्ञात नहीं है, मान 0 से शुरू करें और तब तक बढ़ते रहें जब तक कि क्वेरी शून्य न हो जाए। आप एक चुनिंदा गिनती (*) भी कर सकते हैं, लेकिन इसमें खुद को लंबा समय लग सकता है और कुछ भी अनुकूलित करने में मदद नहीं करेगा। एक बार पृष्ठ संख्या ~60 से अधिक हो जाने पर प्रत्येक क्वेरी को चलने में लगभग 2 सेकंड का समय लगा।

मेरे लिए, पृष्ठ का आकार 5000 था, इसलिए मुझे 0, 5001, 10001, 15001 और इसी तरह की स्थिति में 'नाम' स्ट्रिंग्स की एक सूची मिली। पृष्ठों की संख्या 1000 हो गई और स्मृति में 1000 परिणामों की सूची संग्रहीत करना महंगा नहीं है।

अब, सूची के माध्यम से पुनरावृति करें और इस क्वेरी को चलाएं

SELECT blobCol
FROM my_table
where name >= <pageHeader>
and name < <nextPageHeader>
and city="<any string>"
and id= 1

यह एन बार चलेगा, जहां एन =पहले प्राप्त सूची का आकार। चूंकि 'नाम' प्राथमिक कुंजी कॉलम है, और 'शहर' भी अनुक्रमित है, EXPLAIN दिखाता है कि यह गणना इंडेक्स का उपयोग करके मेमोरी में की जाती है।

अब, प्रत्येक क्वेरी को चलने में मूल 30-40 के बजाय 1 सेकंड का समय लगता है। इसलिए प्रति पृष्ठ 2 सेकंड के पूर्व-प्रसंस्करण समय को मिलाकर, प्रति पृष्ठ कुल समय 30-40 के बजाय 3-4 सेकंड है।

अगर किसी के पास बेहतर समाधान है या इसमें कुछ गड़बड़ है, तो कृपया मुझे बताएं