Yo tuve el mismo problema. Después de investigar durante un tiempo, descubrí que el problema era el problema de intercalación mientras MySQL comparaba texto.
TL;RD: la tabla se creó en una colación mientras que MySQL "pensó" que la variable estaba en otra colación. Por lo tanto, MySQL no puede usar el índice previsto para la consulta.
En mi caso, la tabla fue creada con (latin1 , latin1_swedish_ci ) colación. Para hacer que MySQL use el índice, tuve que cambiar el where cláusula en el procedimiento almacenado de
UPDATE ... WHERE mycolumn = myvariable
a
UPDATE ... WHERE mycolumn =
convert(myvariable using latin1) collate latin1_swedish_ci
Después del cambio, el procedimiento almacenado se parecía a esto:
CREATE PROCEDURE foo.'bar'()
BEGIN
UPDATE mytable SET mycolumn1 = variable1
WHERE mycolumn2 =
convert(variable2 using latin1) collate latin1_swedish_ci
END;
donde (latin1 , latin1_swedish_ci ) es la misma intercalación que mi tableA fue creado con.
Para verificar si MySQL usa el índice o no, puede cambiar el procedimiento almacenado para ejecutar un explain declaración de la siguiente manera:
CREATE PROCEDURE foo.'bar'()
BEGIN
EXPLAIN SELECT * FROM table WHERE mycolumn2 = variable2
END;
En mi caso, el explain El resultado mostró que no se utilizó ningún índice durante la ejecución de la consulta.
Tenga en cuenta que MySQL puede usar el índice cuando ejecuta la consulta solo, pero aún así no usará el índice para la misma consulta dentro de un procedimiento almacenado, lo que tal vez se deba a que de alguna manera MySQL ve la variable en otra intercalación.
Puede encontrar más información sobre el problema de intercalación aquí:http://lowleveldesign.wordpress.com/2013/07/19/diagnosing-collation-issue-mysql-stored-procedure/ Enlace de respaldo:http ://www.codeproject.com/Articles/623272/Diagnosting-a-collation-issue-in-a-MySQL-stored-pro
