J'ai eu le même problème. Après avoir fait des recherches pendant un certain temps, j'ai découvert que le problème était le problème de classement pendant que MySQL comparait du texte.
TL;DR : la table a été créée dans un classement alors que MySQL "pensait" que la variable se trouvait dans un autre classement. Par conséquent, MySQL ne peut pas utiliser l'index destiné à la requête.
Dans mon cas, la table a été créée avec (latin1 , latin1_swedish_ci ) classement. Pour que MySQL utilise l'index, j'ai dû changer le where clause dans la procédure stockée de
UPDATE ... WHERE mycolumn = myvariable
à
UPDATE ... WHERE mycolumn =
convert(myvariable using latin1) collate latin1_swedish_ci
Après le changement, la procédure stockée ressemblait à ceci :
CREATE PROCEDURE foo.'bar'()
BEGIN
UPDATE mytable SET mycolumn1 = variable1
WHERE mycolumn2 =
convert(variable2 using latin1) collate latin1_swedish_ci
END;
où (latin1 , latin1_swedish_ci ) est le même classement que mon tableA a été créé avec.
Pour vérifier si MySQL utilise l'index ou non, vous pouvez modifier la procédure stockée pour exécuter un explain déclaration comme suit :
CREATE PROCEDURE foo.'bar'()
BEGIN
EXPLAIN SELECT * FROM table WHERE mycolumn2 = variable2
END;
Dans mon cas, le explain résultat a montré qu'aucun index n'a été utilisé lors de l'exécution de la requête.
Notez que MySQL peut utiliser l'index lorsque vous exécutez la requête seule, mais n'utilisera toujours pas l'index pour la même requête dans une procédure stockée, peut-être parce que MySQL voit la variable dans un autre classement.
Vous trouverez plus d'informations sur le problème de classement ici :http://lowleveldesign.wordpress.com/2013/07/19/diagnosing-collation-issue-mysql-stored-procedure/ Lien de sauvegarde :http ://www.codeproject.com/Articles/623272/Diagnosing-a-collation-issue-in-a-MySQL-stored-pro
