Повышение производительности в хранимых процессах для длительных транзакций

Question

У меня есть несколько длительных транзакций типа отчета, которые занимают 5-10 минут. Могу ли я увидеть увеличение производительности при использовании хранимых процедур? Это будет значительным?

каждый запрос выполняется один раз за ночь.

Answer 1

Наверное, нет. Хранимые процедуры дают вам преимущество предварительно скомпилированного SQL. Если ваш SQL вызывается нечасто, это преимущество будет бесполезным. Так что если у вас есть SQL, который стоит дорого, потому что сами запросы стоят дорого, то хранимые процедуры не принесут вам значимого преимущества в производительности. Если у вас есть запросы, которые вызываются очень часто и которые сами выполняются быстро, то стоит иметь процедуру.

Answer 2

Скорее всего, нет. Прирост производительности от хранимых процедур, если таковые имеются (зависит от вашего варианта использования), это тот тип, который незаметен в микро - только в макросе.

Запросы типа отчетов - это те, которые объединяют много данных, и если это так, то они будут медленными, независимо от способа выполнения. Только индексация и / или другие физические изменения данных могут сделать это быстрее.

См:

Являются ли хранимые процедуры в целом более эффективными, чем встроенные операторы современных СУБД?

Answer 3

Краткий ответ: нет, хранимые процедуры не улучшат производительность. Для начала, если вы используете параметризованные запросы, нет никакой разницы в производительности между хранимой процедурой и встроенным SQL. Причина в том, что ВСЕ запросы кэшировали планы выполнения, а не только хранимые процедуры. Посмотрите на http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

Если вы не параметризуете свои встроенные запросы, а просто создаете запрос и вставляете «параметры» в виде литералов, то каждый запрос будет выглядеть по-разному для базы данных, и ему потребуется предварительно скомпилировать каждый из них. Так что в этом случае вы будете делать себе одолжение, используя параметры в своем встроенном SQL. И в любом случае вы должны делать это с точки зрения безопасности, иначе вы будете открыты для атак с использованием SQL-инъекций.

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

Answer 4

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

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

Answer 5

да, план запроса для хранимых процедур может быть оптимизирован и даже если он не может, процы предпочтительнее встроенного sql

«Вы бы увидели какое-либо улучшение производительности» - единственный способ узнать наверняка, это попробовать

теоретически хранимые процедуры предварительно анализируют sql и сохраняют план запроса, а не вычисляют каждый раз, так что из-за этого должно быть некоторое ускорение, однако я сомневаюсь, что это будет значительным в 5-10-минутном процессе

если скорость важна, лучше всего посмотреть на план запроса и посмотреть, можно ли его улучшить с помощью различных структур запросов и / или добавив индексы и т. Д.

если скорость не имеет значения, хранимые процы обеспечивают лучшую инкапсуляцию, чем встроенный sql