хранимая процедура 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. Но он настаивает на том, чтобы не использовать индекс. Любая идея? Я думаю, что я близок к концу :)