Ik had hetzelfde probleem. Na een tijdje onderzoek te hebben gedaan, ontdekte ik dat het probleem het sorteerprobleem was terwijl MySQL tekst aan het vergelijken was.
TL;DR: de tabel is in één sortering gemaakt, terwijl MySQL "dacht" dat de variabele in een andere sortering stond. Daarom kan MySQL de index die bedoeld is voor de zoekopdracht niet gebruiken.
In mijn geval is de tabel gemaakt met (latin1 , latin1_swedish_ci ) sortering. Om MySQL de index te laten gebruiken, moest ik de where . wijzigen clausule in de opgeslagen procedure van
UPDATE ... WHERE mycolumn = myvariable
naar
UPDATE ... WHERE mycolumn =
convert(myvariable using latin1) collate latin1_swedish_ci
Na de wijziging zag de opgeslagen procedure er ongeveer zo uit:
CREATE PROCEDURE foo.'bar'()
BEGIN
UPDATE mytable SET mycolumn1 = variable1
WHERE mycolumn2 =
convert(variable2 using latin1) collate latin1_swedish_ci
END;
waar (latin1 , latin1_swedish_ci ) is dezelfde sortering als mijn tableA is gemaakt met.
Om te controleren of MySQL de index gebruikt of niet, kunt u de opgeslagen procedure wijzigen om een explain uit te voeren verklaring als volgt:
CREATE PROCEDURE foo.'bar'()
BEGIN
EXPLAIN SELECT * FROM table WHERE mycolumn2 = variable2
END;
In mijn geval, de explain resultaat toonde aan dat er geen index werd gebruikt tijdens de uitvoering van de zoekopdracht.
Houd er rekening mee dat MySQL de index kan gebruiken wanneer u de query alleen uitvoert, maar de index nog steeds niet voor dezelfde query binnen een opgeslagen procedure zal gebruiken, wat misschien omdat MySQL de variabele op de een of andere manier in een andere sortering ziet.
Meer informatie over het sorteerprobleem vindt u hier:http://lowleveldesign.wordpress.com/2013/07/19/diagnosing-collation-issue-mysql-stored-procedure/ Back-uplink:http ://www.codeproject.com/Articles/623272/Diagnosing-a-collation-issue-in-a-MySQL-stored-pro