Dotazy MySQL jsou rychlé, když jsou spuštěny přímo, ale opravdu pomalé, když jsou spuštěny jako uložený proc

Měl jsem stejný problém. Po chvíli zkoumání jsem zjistil, že problémem byl problém s řazením, zatímco MySQL porovnávala text.

TL;DR: tabulka byla vytvořena v jednom řazení, zatímco MySQL si „myslelo“, že proměnná je v jiném řazení. Proto MySQL nemůže použít index určený pro dotaz.

V mém případě byla tabulka vytvořena pomocí (latin1 , latin1_swedish_ci ) řazení. Aby MySQL používal index, musel jsem změnit where klauzule v uložené proceduře z

    UPDATE ... WHERE mycolumn = myvariable

do

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

Po změně vypadala uložená procedura nějak takto:

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

kde (latin1 , latin1_swedish_ci ) je stejné řazení jako moje tabulkaA byl vytvořen pomocí.

Chcete-li zkontrolovat, zda MySQL používá index nebo ne, můžete změnit uloženou proceduru tak, aby spustila explain následující prohlášení:

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

V mém případě explain výsledek ukázal, že během provádění dotazu nebyl použit žádný index.

Všimněte si, že MySQL může použít index, když spustíte dotaz samostatně, ale přesto nepoužije index pro stejný dotaz uvnitř uložené procedury, což možná proto, že MySQL nějak vidí proměnnou v jiném řazení.

Další informace o problému řazení naleznete zde:http://lowleveldesign.wordpress.com/2013/07/19/diagnosing-collation-issue-mysql-stored-procedure/ Záložní odkaz:http ://www.codeproject.com/Articles/623272/Diagnosing-a-collation-issue-in-a-MySQL-stored-pro