संभवत:प्रत्येक कनेक्शन profiles . का एक पूर्ण तालिका स्कैन कर रहा है . आइए इससे बचने की कोशिश करें। जब एक ही टेबल पर दर्जनों प्रश्न होते हैं, तो ऐसे ताले होते हैं जो InnoDB को "खुद पर ठोकर खाने" का कारण बनते हैं। इनमें से कोई भी योजना क्वेरी को गति देगी और स्पर्श की गई पंक्तियों की संख्या को कम करेगी (इसलिए लॉकिंग कम करें)। सुझाए गए "समग्र" अनुक्रमणिका का उपयोग क्वेरी को गति देगा। लेकिन OR रास्ते में आता है। मुझे अभी भी uniquestring . पर एक इंडेक्स देखने के लिए दो तरकीबें दिखाई देती हैं , लेकिन कुछ या सभी OR . से बचें ।
( (prfls.uniquestring like 'phk5600dcc%')
or (prfls.uniquestring like 'phk5600dcf%')
)
OR अनुकूलित करना कठिन है।
इसे जोड़ें:
INDEX(isconnected, isprofilepresent, uniquestring)
फिर...
योजना ए:
prfls.uniquestring like 'phk5600dc%' AND -- note common prefix
( (prfls.uniquestring like 'phk5600dcc%')
or (prfls.uniquestring like 'phk5600dcf%')
)
यह मानता है कि आप उस सामान्य उपसर्ग का निर्माण कर सकते हैं।
प्लान बी (मोड़ें OR UNION . में ):
( SELECT ...
WHERE prfls.uniquestring like 'phk5600dcc%' AND ...
LIMIT 450 )
UNION ALL -- ? You may want DISTINCT, if there could be dups
( SELECT ...
WHERE prfls.uniquestring like 'phk5600dcf%' AND ... -- the only diff
LIMIT 450 )
LIMIT 450 -- yes, again
योजना ए (यदि व्यावहारिक हो) लगता है . का लाभ उठाती है एक सामान्य प्रारंभिक मूल्य होने के लिए। प्लान बी परवाह किए बिना काम करता है, लेकिन शायद थोड़ा धीमा है, हालांकि अभी भी मूल की तुलना में बहुत तेज है।
अन्य नोट...
झंडे पर इंडेक्स (जिनमें से आपके पास दो हैं) लगभग कभी भी उपयोग नहीं किए जाते हैं। EXPLAIN SELECT ... शायद दिखाएगा कि न तो इस्तेमाल किया गया था। कृपया EXPLAIN प्रदान करें किसी भी SELECT . के लिए जिस पर चर्चा की जरूरत है।
एक UNIQUE KEY एक KEY है , इसलिए USERID . पर अनावश्यक अनुक्रमणिका की आवश्यकता नहीं है ।
limit 450 - आपको कौन सा 450 चाहिए? बिना ORDER BY . के , क्वेरी को आपको कोई भी . देने की अनुमति है 450. (बेशक, शायद यह ठीक है।) (और ORDER BY शायद क्वेरी को धीमा कर देगा।)
मेरे सुझाव समस्या को "समाधान" नहीं करेंगे, लेकिन धीमे-धीमे ध्यान देने योग्य होने से पहले उन्हें कनेक्शन की संख्या बढ़ानी चाहिए।
