Что лучше с точки зрения производительности: хранимая процедура или выполнение запроса с помощью dataadapter?

Question

Я переделываю приложение .NET, которое до сих пор работало медленно.Наши базы данных - Oracle, а код написан на VB.При написании запросов я обычно передаю параметры в функцию среднего уровня, которая создает сырой SQL.У меня есть класс базы данных, который имеет функцию ExecuteQuery, которая принимает строку SQL и возвращает DataTable.Это использует OleDbDataAdapter для запуска запроса к базе данных.

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

Я не знаю, почему это так, но кто-то может сказать мне, что лучше с точки зрения производительности?Или плюсы / минусы в этом?

Заранее спасибо

Answer 1

Хранимые процедуры и динамический SQL имеют одинаковую производительность. Другими словами, нет преимущества в производительности одного над другим. (Между прочим, я ОГРОМНЫЙ сторонник использования сохраненных процедур для всего по множеству других причин, но это не тема под рукой).

Горлышки бутылок могут возникать по многим причинам.

Например, если вы на самом деле генерируете операторы select, очень вероятно, что эти операторы неоптимизированы для данных, необходимых приложению. Например, выполнение SELECT *, которое вытягивает 50 столбцов назад, по сравнению с SELECT ID, Description, которое просто вытягивает две необходимые вам в вашем приложении на данный момент. В этом примере объем данных, которые должны быть прочитаны с диска, переданы по сетевому проводу и помещен в объекты в памяти веб-сервера, не является тривиальным.

Они должны оцениваться в каждом конкретном случае.

Я бы настоятельно рекомендовал, если у вас есть «медленное» приложение, которое необходимо для повышения производительности Самое первое, что вам нужно сделать , - это профилировать приложение. Какая часть этого работает медленно? Это может быть внутри сервера базы данных, это может быть на вашем среднем уровне, это может быть даже функцией вашей пропускной способности сети или ограничений памяти / нагрузки на вашем веб-сервере. Черт возьми, может быть, где-то там скрывается команда WAIT, которую поместил какой-то предыдущий программист, покинувший компанию ...

Короче говоря, вы абсолютно не знаете, с чего начать. Так что смотреть на реальный код преждевременно. Зайдите в профиль приложения и посмотрите, где все замедляется. Вы можете обнаружить, что производительность может радикально улучшиться, просто добавив больше памяти на сервер базы данных ... Это гораздо более дешевая альтернатива, чем переписывание, тестирование и развертывание огромных объемов кода.

Answer 2

хранимая процедура определенно будет иметь лучшую производительность по сравнению с созданием необработанного запроса в коде и его выполнением, но важно понимать, что эта разница в производительности не будет вашей проблемой производительности, есть много других вещей, которые будут влияет на производительность гораздо больше, чем просто превращение простого запроса в хранимую процедуру, даже если вы запускаете хранимую процедуру и обрабатываете результаты с помощью адаптеров, таблиц данных, наборов данных, вы по-прежнему несете большую производительность, особенно если вы передаете эти большие объекты вокруг (я видел случаи, когда наборы данных возвращаются, завернутые в вызовы веб-служб), поэтому не сосредотачивайтесь на этом, сосредоточьтесь на кэшировании данных, наличии хорошего запроса, создании надлежащих индексов, минимизации использования наборов данных, таблицы данных, которые дадут больше преимуществ, чем просто перемещение запросов к хранимым процедурам