MySQL заявките са бързи, когато се изпълняват директно, но наистина бавни, когато се изпълняват като съхранена процедура

Имах същия проблем. След като проучвах известно време, разбрах, че проблемът е проблемът със съпоставянето, докато MySQL сравнява текста.

TL;DR: таблицата е създадена в едно съпоставяне, докато 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;

където (latin1 , latin1_swedish_ci ) е същото съпоставяне като моята таблицаA е създаден с.

За да проверите дали MySQL използва индекса или не, можете да промените съхранената процедура, за да стартирате explain изявление, както следва:

    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