Miałem ten sam problem. Po pewnym czasie badań odkryłem, że problem polegał na tym, że MySQL porównywał tekst.
TL;DR: tabela została utworzona w jednym zestawieniu, podczas gdy MySQL „pomyślał”, że zmienna jest w innym zestawieniu. Dlatego MySQL nie może używać indeksu przeznaczonego dla zapytania.
W moim przypadku tabela została utworzona za pomocą (latin1 , latin1_swedish_ci ) zestawienie. Aby MySQL używał indeksu, musiałem zmienić where klauzula w procedurze składowanej z
UPDATE ... WHERE mycolumn = myvariable
do
UPDATE ... WHERE mycolumn =
convert(myvariable using latin1) collate latin1_swedish_ci
Po zmianie procedura składowana wyglądała mniej więcej tak:
CREATE PROCEDURE foo.'bar'()
BEGIN
UPDATE mytable SET mycolumn1 = variable1
WHERE mycolumn2 =
convert(variable2 using latin1) collate latin1_swedish_ci
END;
gdzie (latin1 , latin1_swedish_ci ) jest tym samym zestawieniem, co moja tabelaA został utworzony za pomocą.
Aby sprawdzić, czy MySQL używa indeksu, czy nie, możesz zmienić procedurę składowaną, aby uruchomić explain następujące oświadczenie:
CREATE PROCEDURE foo.'bar'()
BEGIN
EXPLAIN SELECT * FROM table WHERE mycolumn2 = variable2
END;
W moim przypadku explain wynik pokazał, że podczas wykonywania zapytania nie został użyty żaden indeks.
Zwróć uwagę, że MySQL może używać indeksu, gdy uruchamiasz samo zapytanie, ale nadal nie użyje indeksu dla tego samego zapytania wewnątrz procedury składowanej, co może być spowodowane tym, że MySQL widzi zmienną w innym zestawieniu.
Więcej informacji na temat sortowania można znaleźć tutaj:http://lowleveldesign.wordpress.com/2013/07/19/diagnosing-collation-issue-mysql-stored-procedure/ Link do kopii zapasowej:http ://www.codeproject.com/Articles/623272/Diagnosing-a-collation-issue-in-a-MySQL-stored-pro
