प्रश्न स्थानीय सेटअप पर कैश किया गया है, लेकिन सर्वर पर कभी नहीं?

Question

मुझे किसी प्रोजेक्ट पर क्वेरी कैश के साथ बहुत सारी परेशानी हो रही है: मैं MySQL का पेर्कोना स्वाद चला रहा हूं, दोनों ही मेरे स्थानीय विकास मशीन पर उत्पादन सर्वर पर समान संस्करण हैं। अब, क्वेरी कैश को सक्षम करने से मुझे मेरी स्थानीय मशीन पर उत्कृष्ट परिणाम मिलते हैं: लगभग सभी प्रश्न जिन्हें कैश किया जाना चाहिए, प्रभावी रूप से हैं।

अब, वही प्रश्न उत्पादन सर्वर पर कैश नहीं किए जा रहे हैं। सब ठीक वही है; mysql चर, डेटाबेस सामग्री, कोडबेस, उपयोगकर्ता में लॉग इन, .. लेकिन उत्पादन पर केवल एक मुट्ठी भर प्रश्नों को कैश किया जा रहा है, सबसे महत्वपूर्ण सभी को छोड़ दिया जा रहा है। और मैं यह नहीं समझ सकता कि क्यों :-)

तो, समाधान की तलाश में, मैं निम्नलिखित क्वेरी के साथ काम कर रहा हूं, विषय तालिका से नवीनतम 3 विषयों का चयन करने के लिए उपयोग किया जाता है: (यह सबसे अधिक "भारी" है !

+------------------------------+----------+ 
| Variable_name    | Value | 
+------------------------------+----------+ 
| have_query_cache    | YES  | 
| query_cache_limit   | 1048576 | 
| query_cache_min_res_unit  | 4096  | 
| query_cache_size    | 10485760 | 
| query_cache_strip_comments | OFF  | 
| query_cache_type    | ON  | 
| query_cache_wlock_invalidate | OFF  | 
+------------------------------+----------+ 

ऊपर क्वेरी चल रहा है: क्वेरी और एक मैं निश्चित रूप से चाहते कैश हो जाने की है)

SELECT `topic`.* FROM `topics` AS `topic` 
LEFT OUTER JOIN `topics` AS `topic_helper` 
ON (`topic`.`id` = `topic_helper`.`id` 
     AND `topic_helper`.`created_on` < `topic`.`created_on`) 
GROUP BY `topic`.`id` HAVING COUNT(*) < 3 
ORDER BY `topic`.`created_on` DESC; 

तो, शुरू करने के लिए, SHOW VARIABLES LIKE '%query_cache% मुझे एक ही परिणाम दोनों उत्पादन पर के रूप में स्थानीय देते हैं, पहले रन के बाद स्थानीय रूप से कैश किया जाता है, क्योंकि SHOW PROFILE स्पष्ट रूप से मुझे बताता है n कान के निशान का अंत कान:

| Waiting for query cache lock | 0.000001 | 
| Waiting on query cache mutex | 0.000001 | 
| freeing items     | 0.000000 | 
| storing result in query cache | 0.000002 | 
| logging slow query    | 0.000001 | 
| cleaning up     | 0.000006 | 
+--------------------------------+----------+ 

दूसरा कॉल कैश से क्वेरी को अपेक्षित रूप से देता है।

उत्पादन सर्वर पर, यह क्वेरी चलाने से इसे कैश में कभी भी स्टोर नहीं किया जाएगा। परिणाम सेट बिल्कुल वही है, और स्पष्ट रूप से कोई कथन नहीं किया जा रहा है जो क्वेरी कैशिंग को अमान्य कर देगा (मैनुअल के अनुसार http://dev.mysql.com/doc/refman/5.1/en/query-cache-operation.html पर - मुझे यकीन है कि उपरोक्त क्वेरी कैश होने के लिए आवश्यकताओं का अनुपालन करती है।)

पूर्णता खातिर, उत्पादन सर्वर पर है कि समान क्वेरी SHOW PROFILE का पूरा उत्पादन, के लिए यहां चिपकाया जाता है: http://pastebin.com/7Jm5rmVd

इसके अलावा, यह ध्यान देने योग्य है कि हालांकि विन्यास दोनों सर्वर पर बिल्कुल वैसा ही है, अपने स्थानीय संस्करण 5.5.27 है, उत्पादन 5.5.17-55 पर एक से थोड़ा नया है। क्या यह हो सकता है कि यह समस्या है ..?

मैं उत्पादन सर्वर के रूप में दोनों अपने स्थानीय सर्वर से पूर्ण SHOW VARIABLES; उत्पादन की तुलना में अगर कुछ भी याद आ रही थी को देखने के लिए, लेकिन कुछ भी प्रणाली समय क्षेत्र के अलावा अलग है और पथ की फाइलें आदि लॉग इन करने की ..

तो, हो सकता है आप में से कोई भी जानता है कि आगे कहां देखना है? या कोई संकेत है कि यह क्या हो सकता है?

Answer 1

हम यहां परकोना सर्वर का उपयोग करते हैं, और समुदाय MySQL भी।

क्वेरी कैश शक्तिशाली हैं - और शायद जटिल हैं। बदतर चीज MySQL कर सकती है कुछ पुराने कैश डेटा लौटाती है।

न केवल MySQL क्वेरी को कैश करता है, बल्कि डेटाबेस डेटा भी कैश करता है - और अतिरिक्त प्रदर्शन के लिए अनुक्रमणिका का उपयोग करता है।

कुछ भी जो क्वेरी कैश को अमान्य कर सकता है, इसे अमान्य करता है।

अंगूठे के नियम के रूप में - हम इस पर बहुत ध्यान केंद्रित नहीं करते कि यह कैश किया जा रहा है या नहीं ...हम भरोसा करते हैं कि MySQL समझदारी से कार्य करता है - अगर किसी भी कारण से ऐसा लगता है कि कुछ कैश नहीं किया जाना चाहिए, तो यह कैश नहीं करता है। हालांकि हम क्या करते हैं - यह सुनिश्चित कर लें कि हमारे प्रश्न यथासंभव कुशल और सरल हैं।

यदि मैं यह कह सकता हूं - मुझे लगता है कि आप क्वेरी कैश के बावजूद गंभीर स्केलेबिलिटी समस्याओं को मारने जा रहे हैं यदि आपकी उदाहरण क्वेरी "आपके सबसे अधिक उपयोग में से एक" है। सर्वर व्यस्त होने के बाद यह बिना किसी पैर के कुत्ते की तरह दौड़ने जा रहा है!

आपकी पेस्टबिन प्रविष्टि के अनुसार - आपके पास बाहरी शामिल होने (या ग्रुप बीईएस) के कारण कम से कम एक अस्थायी तालिका बनाई जा रही है।

मैं सभी सामान्यीकरण के लिए हूं - लेकिन कभी-कभी प्रदर्शन वैकल्पिक मार्ग की मांग करता है।

क्या आप किसी भी प्रकार के लुकअप/सारांश तालिका में स्वयं उस डेटा को कैश नहीं कर सकते हैं? ट्रिगर्स आपका मित्र यहां हो सकते हैं :)