хранимая процедура mysql медленнее в 20 раз, чем стандартный запрос

у меня есть 10 таблиц с той же структурой, кроме имени таблицы.

у меня есть sp (хранимая процедура), определенная следующим образом:

 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)

Я звоню sp со следующей строкой:

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

Затем я открыл новое стандартное окно запроса. Я только что скопировал запрос выше. Затем заменили @ param1 на «тест».

Это выполняется за 0,321 с и примерно в 20 раз быстрее, чем хранимая процедура.

Я неоднократно менял значение параметра для предотвращения кэширования результата. Но это не изменило результат. SP примерно в 20 раз медленнее, чем эквивалентный стандартный запрос.

Пожалуйста, вы можете помочь мне выяснить, почему это происходит?

Кто-нибудь сталкивался с подобными проблемами?

Я использую MySQL 5.0.51 на Windows Server 2008 R2 64 бит.

редактировать: я использую Navicat для теста.

Любая идея будет полезна для меня.

EDIT1:

Я только что провела тест в соответствии с ответом Бармара.

Наконец, я изменил SP, как показано ниже, с одной строкой:

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

Затем сначала я выполнил стандартный запрос

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

После того, как я назвал мой sp:

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

Так что я полностью изменил положение, но ничего не изменилось. И я вызвал командное окно sp from mysql вместо navicat. Это дало тот же результат. Я все еще застрял на этом.

мой sp ddl:

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

И col1 и col2 объединены в индекс.

Вы можете сказать, почему тогда вы не используете стандартный запрос? Мой дизайн программного обеспечения не подходит для этого. Я должен использовать хранимую процедуру. Так что эта проблема очень важна для меня.

EDIT2:

Я получил информацию профиля запроса. Большая разница из-за "отправки строки данных" в информации профиля SP. Отправка данных занимает% 99 времени выполнения запроса. Я делаю тест на локальном сервере базы данных. Я не подключаюсь с удаленного компьютера.

SP Профиль Информация

Информация о профиле запроса

Я попробовал заявление индекса силы как ниже в моем sp. Но результат тот же.

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

Я изменил SP, как показано ниже.

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

Это дало этот результат:

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

Затем я выполнил запрос ниже.

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

Результат:

 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

Я использую утверждение FORCE INDEX в SP. Но он настаивает на том, чтобы не использовать индекс. Любая идея? Я думаю, что я близок к концу :)

Ответы на вопрос(4)

Ваш ответ на вопрос