MySQL-frågor är snabba när de körs direkt men riktigt långsamma när de körs som lagrade proc

Jag hade samma problem. Efter att ha undersökt ett tag upptäckte jag att problemet var sorteringsproblemet medan MySQL jämförde text.

TL;DR: tabellen skapades i en kollation medan MySQL "trodde" att variabeln fanns i en annan sortering. Därför kan MySQL inte använda det index som är avsett för frågan.

I mitt fall skapades tabellen med (latin1 , latin1_swedish_ci ) sammanställning. För att få MySQL att använda indexet var jag tvungen att ändra where klausul i den lagrade proceduren från

    UPDATE ... WHERE mycolumn = myvariable

till

    UPDATE ... WHERE mycolumn = 
        convert(myvariable using latin1) collate latin1_swedish_ci

Efter ändringen såg den lagrade proceduren ut ungefär så här:

    CREATE PROCEDURE foo.'bar'()
    BEGIN
        UPDATE mytable SET mycolumn1 = variable1
        WHERE mycolumn2 = 
            convert(variable2 using latin1) collate latin1_swedish_ci
    END;

där (latin1 , latin1_swedish_ci ) är samma sortering som min tabellA skapades med.

För att kontrollera om MySQL använder indexet eller inte, kan du ändra den lagrade proceduren för att köra en explain uttalande enligt följande:

    CREATE PROCEDURE foo.'bar'()
    BEGIN
        EXPLAIN SELECT * FROM table WHERE mycolumn2 = variable2
    END;

I mitt fall är explain Resultatet visade att inget index användes under körningen av frågan.

Observera att MySQL kan använda indexet när du kör frågan ensam, men fortfarande inte kommer att använda indexet för samma fråga i en lagrad procedur, vilket kanske beror på att MySQL på något sätt ser variabeln i en annan sammanställning.

Mer information om sorteringsfrågan finns här:http://lowleveldesign.wordpress.com/2013/07/19/diagnosing-collation-issue-mysql-stored-procedure/ Säkerhetskopieringslänk:http ://www.codeproject.com/Articles/623272/Diagnosing-a-collation-issue-in-a-MySQL-stored-pro