MySQLクエリは、直接実行すると高速ですが、ストアドプロシージャとして実行すると非常に低速になります

私も同じ問題を抱えていました。しばらく調べてみたところ、MySQLがテキストを比較しているときに問題が照合の問題であることがわかりました。

TL; DR： テーブルは1つの照合で作成され、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 ）は私の<strong> tableAと同じ照合ですで作成されました。

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