Ho avuto lo stesso problema. Dopo aver cercato per un po', ho scoperto che il problema era il problema delle regole di confronto mentre MySQL confrontava il testo.
TL;DR: la tabella è stata creata in una confronto mentre MySQL "pensava" che la variabile fosse in un'altra confronto. Pertanto, MySQL non può utilizzare l'indice previsto per la query.
Nel mio caso, la tabella è stata creata con (latin1 , latin1_swedish_ci ) collazione. Per fare in modo che MySQL utilizzi l'indice, ho dovuto cambiare where clausola nella procedura memorizzata da
UPDATE ... WHERE mycolumn = myvariable
a
UPDATE ... WHERE mycolumn =
convert(myvariable using latin1) collate latin1_swedish_ci
Dopo la modifica, la procedura memorizzata era simile a questa:
CREATE PROCEDURE foo.'bar'()
BEGIN
UPDATE mytable SET mycolumn1 = variable1
WHERE mycolumn2 =
convert(variable2 using latin1) collate latin1_swedish_ci
END;
dove (latino1 , latin1_swedish_ci ) è lo stesso confronto che il mio tableA è stato creato con.
Per verificare se MySQL utilizza l'indice o meno, puoi modificare la procedura memorizzata per eseguire un explain dichiarazione come segue:
CREATE PROCEDURE foo.'bar'()
BEGIN
EXPLAIN SELECT * FROM table WHERE mycolumn2 = variable2
END;
Nel mio caso, il explain risultato ha mostrato che nessun indice è stato utilizzato durante l'esecuzione della query.
Nota che MySQL può utilizzare l'indice quando esegui la query da solo, ma non utilizzerà comunque l'indice per la stessa query all'interno di una procedura memorizzata, forse perché in qualche modo MySQL vede la variabile in un'altra confronto.
Ulteriori informazioni sul problema delle regole di confronto sono disponibili qui:http://lowleveldesign.wordpress.com/2013/07/19/diagnosing-collation-issue-mysql-stored-procedure/ Link di backup:http ://www.codeproject.com/Articles/623272/Diagnosing-a-collation-issue-in-a-MySQL-stored-pro
