MySQL-forespørgsler er hurtige, når de køres direkte, men virkelig langsomme, når de køres som lagret proc

Jeg havde samme problem. Efter at have undersøgt et stykke tid fandt jeg ud af, at problemet var sorteringsproblemet, mens MySQL sammenlignede tekst.

TL;DR: tabellen blev oprettet i én kollation, mens MySQL "troede", at variablen var i en anden kollation. Derfor kan MySQL ikke bruge det indeks, der er beregnet til forespørgslen.

I mit tilfælde blev tabellen oprettet med (latin1 , latin1_swedish_ci ) sammenstilling. For at få MySQL til at bruge indekset, var jeg nødt til at ændre where klausul i den lagrede procedure fra

    UPDATE ... WHERE mycolumn = myvariable

til

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

Efter ændringen så den lagrede procedure sådan ud:

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

hvor (latin1 , latin1_swedish_ci ) er den samme samling som min tabelA blev oprettet med.

For at kontrollere, om MySQL bruger indekset eller ej, kan du ændre den lagrede procedure for at køre en explain erklæring som følger:

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

I mit tilfælde er explain Resultatet viste, at der ikke blev brugt noget indeks under udførelsen af ​​forespørgslen.

Bemærk, at MySQL muligvis bruger indekset, når du kører forespørgslen alene, men vil stadig ikke bruge indekset til den samme forespørgsel i en lagret procedure, hvilket måske skyldes, at MySQL på en eller anden måde ser variablen i en anden kollation.

Flere oplysninger om sorteringsproblemet kan findes her:http://lowleveldesign.wordpress.com/2013/07/19/diagnosing-collation-issue-mysql-stored-procedure/ Link til backup:http ://www.codeproject.com/Articles/623272/Diagnosing-a-collation-issue-in-a-MySQL-stored-pro