MySQL क्वेरीज़ तेज़ होती हैं जब सीधे चलती हैं लेकिन वास्तव में धीमी होती हैं जब संग्रहित प्रो के रूप में चलती हैं

मुझे भी यही समस्या थी। थोड़ी देर के लिए शोध करने के बाद, मुझे पता चला कि समस्या संयोजन की समस्या थी जबकि MySQL पाठ की तुलना कर रहा था।

टीएल; डॉ: तालिका एक संयोजन में बनाई गई थी जबकि MySQL "सोचा" चर दूसरे संयोजन में था। इसलिए, MySQL क्वेरी के लिए इच्छित अनुक्रमणिका का उपयोग नहीं कर सकता है।

मेरे मामले में, तालिका (latin1 .) के साथ बनाई गई थी , latin1_swedish_ci ) मिलान। MySQL को इंडेक्स का उपयोग करने के लिए, मुझे where बदलना पड़ा संग्रहीत कार्यविधि में खंड

    UPDATE ... WHERE mycolumn = myvariable

करने के लिए

    UPDATE ... WHERE mycolumn = 
        convert(myvariable using latin1) collate latin1_swedish_ci

परिवर्तन के बाद, संग्रहीत कार्यविधि कुछ इस तरह दिखी:

    CREATE PROCEDURE foo.'bar'()
    BEGIN
        UPDATE mytable SET mycolumn1 = variable1
        WHERE mycolumn2 = 
            convert(variable2 using latin1) collate latin1_swedish_ci
    END;

जहां (लैटिन1 , latin1_swedish_ci ) वही संयोजन है जो मेरी tableA . है के साथ बनाया गया था।

यह जांचने के लिए कि MySQL अनुक्रमणिका का उपयोग करता है या नहीं, आप explain run चलाने के लिए संग्रहीत कार्यविधि को बदल सकते हैं निम्नलिखित के रूप में बयान:

    CREATE PROCEDURE foo.'bar'()
    BEGIN
        EXPLAIN SELECT * FROM table WHERE mycolumn2 = variable2
    END;

मेरे मामले में, explain परिणाम से पता चला कि क्वेरी के निष्पादन के दौरान किसी अनुक्रमणिका का उपयोग नहीं किया गया था।

ध्यान दें कि जब आप अकेले क्वेरी चलाते हैं तो MySQL अनुक्रमणिका का उपयोग कर सकता है, लेकिन फिर भी संग्रहीत कार्यविधि के अंदर उसी क्वेरी के लिए अनुक्रमणिका का उपयोग नहीं करेगा, जो शायद इसलिए कि MySQL किसी अन्य संयोजन में चर को देखता है।

कोलेशन मुद्दे पर अधिक जानकारी यहां मिल सकती है:http://lowleveldesign.wordpress.com/2013/07/19/diagnosing-collation-issue-mysql-stored-procedure/ बैक अप लिंक:http ://www.codeproject.com/Articles/623272/Diagnosing-a-collation-issue-in-a-MySQL-stored-pro