Die gespeicherte mysql-Prozedur ist 20-mal langsamer als die Standardabfrage

Ich habe 10 Tabellen mit der gleichen Struktur außer Tabellennamen.

Ich habe eine sp (gespeicherte Prozedur) wie folgt definiert:

 select * from table1 where (@param1 IS NULL OR col1=@param1)
 UNION ALL
 select * from table2 where (@param1 IS NULL OR col1=@param1)
 UNION ALL
 ...
 ...
 UNION ALL
 select * from table10 where (@param1 IS NULL OR col1=@param1)

Ich rufe den sp mit folgender leitung an:

call mySP('test')  //it executes in 6,836s

Dann öffnete ich ein neues Standard-Abfragefenster. Ich habe gerade die Anfrage oben kopiert. Dann wird @ param1 durch 'test' ersetzt.

Dies wurde in 0,321s ausgeführt und ist ungefähr 20-mal schneller als die gespeicherte Prozedur.

Ich habe den Parameterwert wiederholt geändert, um zu verhindern, dass das Ergebnis zwischengespeichert wird. Dies änderte jedoch nichts am Ergebnis. Der SP ist ungefähr 20-mal langsamer als die entsprechende Standardabfrage.

Können Sie mir bitte helfen, herauszufinden, warum dies geschieht?

Ist jemand auf ähnliche Probleme gestoßen?

Ich verwende mySQL 5.0.51 unter Windows Server 2008 R2 64-Bit.

Bearbeiten: Ich benutze Navicat zum Testen.

Jede Idee wird für mich hilfreich sein.

EDIT1:

Ich habe gerade einen Test gemäß Barmars Antwort durchgeführt.

Endlich habe ich die sp wie folgt mit einer einzigen Zeile geändert:

 SELECT * FROM table1 WHERE col1=@param1 AND col2=@param2

Dann habe ich zuerst die Standardabfrage ausgeführt

 SELECT * FROM table1 WHERE col1='test' AND col2='test'  //Executed in 0.020s

Nachdem ich den my sp angerufen habe:

 CALL MySp('test','test')    //Executed in 0.466s

Also habe ich die where-Klausel komplett geändert, aber nichts geändert. Und ich rief die SP von MySQL-Befehlsfenster anstelle von Navicat. Es gab das gleiche Ergebnis. Ich stecke immer noch fest.

mein sp ddl:

 CREATE DEFINER = `myDbName`@`%`
 PROCEDURE `MySP` (param1 VARCHAR(100), param2 VARCHAR(100))
 BEGIN
    SELECT * FROM table1 WHERE col1=param1 AND col2=param2
 END

Und col1 und col2 werden indiziert kombiniert.

Man könnte sagen, warum benutzt man dann keine Standardabfrage? Mein Softwaredesign ist dafür nicht geeignet. Ich muss gespeicherte Prozedur verwenden. Deshalb ist mir dieses Problem sehr wichtig.

EDIT2:

Ich habe Informationen zum Abfrageprofil erhalten. Ein großer Unterschied besteht darin, dass in den SP-Profilinformationen "Datenzeilen gesendet" werden. Das Senden des Datenteils benötigt% 99 der Ausführungszeit der Abfrage. Ich mache einen Test auf einem lokalen Datenbankserver. Ich verbinde mich nicht von einem entfernten Computer.

SP Profilinformationen

Abfrageprofilinformationen

Ich habe versucht, Index-Anweisung wie unten in meinem SP zu erzwingen. Aber das gleiche Ergebnis.

 SELECT * FROM table1 FORCE INDEX (col1_col2_combined_index) WHERE col1=@param1 AND col2=@param2

Ich habe sp wie unten geändert.

 EXPLAIN SELECT * FROM table1 FORCE INDEX (col1_col2_combined_index) WHERE col1=param1 AND col2=param2

Dies ergab folgendes Ergebnis:

 id:1
 select_type=SIMPLE
 table:table1
 type=ref
 possible_keys:NULL
 key:NULL
 key_len:NULL
 ref:NULL
 rows:292004
 Extra:Using where

Dann habe ich die Abfrage unten ausgeführt.

 EXPLAIN SELECT * FROM table1 WHERE col1='test' AND col2='test'

Ergebnis ist:

 id:1
 select_type=SIMPLE
 table:table1
 type=ref
 possible_keys:col1_co2_combined_index
 key:col1_co2_combined_index
 key_len:76
 ref:const,const
 rows:292004
 Extra:Using where

Ich verwende die FORCE INDEX-Anweisung in SP. Es besteht jedoch darauf, keinen Index zu verwenden. Irgendeine Idee? Ich denke ich bin kurz vor dem Ende :)

Antworten auf die Frage(4)

Ihre Antwort auf die Frage