Ich hatte das gleiche Problem. Nachdem ich eine Weile recherchiert hatte, fand ich heraus, dass das Problem das Sortierungsproblem war, während MySQL Text vergleicht.
TL;DR: Die Tabelle wurde in einer Sortierung erstellt, während MySQL „dachte“, die Variable befinde sich in einer anderen Sortierung. Daher kann MySQL den für die Abfrage vorgesehenen Index nicht verwenden.
In meinem Fall wurde die Tabelle mit (latin1 erstellt , latin1_swedish_ci ) Zusammenstellung. Damit MySQL den Index verwendet, musste ich das where ändern -Klausel in der gespeicherten Prozedur von
UPDATE ... WHERE mycolumn = myvariable
zu
UPDATE ... WHERE mycolumn =
convert(myvariable using latin1) collate latin1_swedish_ci
Nach der Änderung sah die gespeicherte Prozedur etwa so aus:
CREATE PROCEDURE foo.'bar'()
BEGIN
UPDATE mytable SET mycolumn1 = variable1
WHERE mycolumn2 =
convert(variable2 using latin1) collate latin1_swedish_ci
END;
wobei (latin1 , latin1_swedish_ci ) ist dieselbe Sortierung wie meine tableA wurde erstellt mit.
Um zu überprüfen, ob MySQL den Index verwendet oder nicht, können Sie die gespeicherte Prozedur so ändern, dass ein explain ausgeführt wird Anweisung wie folgt:
CREATE PROCEDURE foo.'bar'()
BEGIN
EXPLAIN SELECT * FROM table WHERE mycolumn2 = variable2
END;
In meinem Fall das explain Das Ergebnis zeigte, dass während der Ausführung der Abfrage kein Index verwendet wurde.
Beachten Sie, dass MySQL den Index verwenden kann, wenn Sie die Abfrage alleine ausführen, aber dennoch nicht den Index für dieselbe Abfrage innerhalb einer gespeicherten Prozedur verwendet, was möglicherweise daran liegt, dass MySQL die Variable irgendwie in einer anderen Sortierung sieht.
Weitere Informationen zum Sortierungsproblem finden Sie hier:http://lowleveldesign.wordpress.com/2013/07/19/diagnosing-collation-issue-mysql-stored-procedure/ Sicherungslink:http ://www.codeproject.com/Articles/623272/Diagnosing-a-collation-issue-in-a-MySQL-stored-pro
