Eu tive o mesmo problema. Depois de pesquisar por um tempo, descobri que o problema era o problema de agrupamento enquanto o MySQL estava comparando texto.
TL;DR: a tabela foi criada em um agrupamento enquanto o MySQL "pensava" que a variável estava em outro agrupamento. Portanto, o MySQL não pode usar o índice pretendido para a consulta.
No meu caso, a tabela foi criada com (latin1 , latin1_swedish_ci ) colação. Para fazer o MySQL usar o índice, tive que alterar o
where cláusula no procedimento armazenado de UPDATE ... WHERE mycolumn = myvariable
para
UPDATE ... WHERE mycolumn =
convert(myvariable using latin1) collate latin1_swedish_ci
Após a alteração, o procedimento armazenado ficou assim:
CREATE PROCEDURE foo.'bar'()
BEGIN
UPDATE mytable SET mycolumn1 = variable1
WHERE mycolumn2 =
convert(variable2 using latin1) collate latin1_swedish_ci
END;
onde (latin1 , latin1_swedish_ci ) é o mesmo agrupamento que minha tableA foi criado com.
Para verificar se o MySQL usa o índice ou não, você pode alterar o procedimento armazenado para executar um
explain declaração a seguir: CREATE PROCEDURE foo.'bar'()
BEGIN
EXPLAIN SELECT * FROM table WHERE mycolumn2 = variable2
END;
No meu caso, o
explain resultado mostrou que nenhum índice foi usado durante a execução da consulta. Observe que o MySQL pode usar o índice quando você executa a consulta sozinho, mas ainda não usará o índice para a mesma consulta dentro de um procedimento armazenado, talvez porque de alguma forma o MySQL vê a variável em outro agrupamento.
Mais informações sobre o problema de agrupamento podem ser encontradas aqui:http://lowleveldesign.wordpress.com/2013/07/19/diagnosing-collation-issue-mysql-stored-procedure/ Link de backup:http ://www.codeproject.com/Articles/623272/Diagnosing-a-collation-issue-in-a-MySQL-stored-pro
