2015-02-12 5 views
0

У меня есть хранимая функция, которую я портировал с SQL Server, что очень медленно для MySql. Поскольку мое приложение должно поддерживать как SQL Server, так и MySql (через драйверы ODBC), мне нужна эта функция. Сохраненная функция обычно используется в предложении «where», но она медленная, даже если она находится только в предложении «select».улучшение производительности хранимой функции mysql

Есть ли какие-либо уловки для улучшения производительности функций? Может быть, какие-нибудь полезные инструменты, указывающие на потенциальные проблемы с сохраненной функцией или медленные точки?

Это сложные функции. Таким образом, хотя одно утверждение в функции относительно быстро, все, что собрано, происходит медленно.

Кроме того, в этих функциях используются виды. Не знаю, насколько это влияет на вещи. Кажется, что взгляды проходят в разумные сроки.

Я знаю, что я не придаю особого значения, но я больше ищу инструмент для повышения производительности или некоторые рекомендации по повышению производительности встроенных функций высокого уровня.

Я видел различные сообщения в Интернете, предлагая людям не использовать функции в предложениях «где», но я как бы застрял, так как хочу идти туда и обратно между SQL Server и MySql с одним и тем же исполняемым файлом, а функции для сложного внедрения непосредственно в SQL в моем приложении.

Edit на основе Gruber ответа, чтобы разъяснить вещи с примером: Вот пример запроса:

SELECT count(*) FROM inv USE INDEX(inv_invsku) WHERE invsku >= 'PBM116-01' AND WHMSLayer_IS_LOC_ACCESSIBLE('', 'PFCSYS ', invloc) > 0 ORDER BY invsku; 

Если я избавлюсь от вызова IS_LOC_ACCESSIBLE, это значительно быстрее. IS_LOC_ACCESSIBLE является лишь одной из трех таких функций. Он содержит множество операторов IF, запросы других таблиц и представлений и т. Д. Вот почему я называю это «сложным» из-за всех дополнительных логических и условных путей.

+0

MySQL будет вызывать эту функцию для каждой строки, которая в противном случае соответствует предложению WHERE. Оптимизатор не вытащит какой-либо код из функции, чтобы все SELECT выполнялось быстрее. Самое лучшее, что мы можем сделать, это посмотреть на функцию и посмотреть, можно ли (1) ускорить ее, или (2) каким-то образом вытащить то, что она делает из функции, и сделать ее более эффективно. Вы хотите показать нам эту функцию, а также SHOW CREATE TABLE/VIEW? –

ответ

0

Вы можете попробовать использовать профилировщик запросов, например, тот, который включен в dbForge Studio, и попытаться выяснить, в чем именно находятся узкие места.

Возможно, ваши таблицы неправильно проиндексированы?

Иногда вы можете добиться хороших улучшений в MySQL (и SQL Server), перемещая вещи в своих запросах, создавая идентичный вывод, но изменяя внутренний путь выполнения. Например, попробуйте удалить сложное предложение WHERE, используя сложный код как вывод из завернутого оператора SELECT, который вы можете использовать в дальнейшем WHERE.

+0

Я все еще обрабатываю ваш ответ, но, надеюсь, мое обновление проясняет ситуацию. Я попробовал вашу идею подзапроса (или, по крайней мере, мою интерпретацию идеи), и это не помогло. – user3329922

+0

Профилирует запрос на фактические используемые функции или просто запрос, который использует эту функцию? Все профилировщики, которых я знаю, просто смотрят на запрос, а не на функции, вызываемые в запросе. Мне действительно нужна функция профилирования. – user3329922

+0

Для идеи «движущихся вещей вокруг», как бы вы предложили мне это сделать? Я дал вам пример select statement, который я тогда взял и попробовал вашу идею суб-запроса (или, по крайней мере, мою интерпретацию вашей идеи). – user3329922