Есть ли значительное увеличение производительности при использовании хранимых процедур?

Question

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

Answer 1

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

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

Answer 2

Я бы быстро взглянул на Хранимые процедуры - ЗЛО .

Answer 3

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

Если бы я был вами, я бы сначала искал добавление индексов там, где это необходимо. Также запустите инструмент profiling , чтобы проверить, что занимает много времени и нужно ли изменить этот sql, например, добавление дополнительных предложений Where или ограничение результирующего набора.

Вы должны рассмотреть кэширование , где вы можете.

Answer 4

Хранимые процедуры не сделают вещи быстрее.

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

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

Приложение, которое "работает медленно в последнее время", не нуждается в изменениях кодирования.

1. Мера. Мера. Мера. «медленный» не имеет большого значения, когда дело доходит до настройки производительности. Что медленно? Какая именно транзакция медленная? Какой стол медленный? Фокус.

2. Контроль всех изменений. Все. Что изменилось? ОС патч? СУБД меняются? Изменение приложения? Что-то изменилось, чтобы замедлить ход событий.

3. Проверка ограничений в масштабе. Таблица замедляется, потому что 80% данных - это история, которую вы используете для составления отчетов один раз в год?

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

Answer 5

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

Answer 6

После того, как вы закончите свое исследование, вы поймете, что есть две крайние точки зрения на противоположной стороне спектра. Исторически сложилось так, что сообщество Java выступало против процедур хранения данных из-за доступности таких фреймворков, как hibernate, и наоборот. Сообщество .NET использовало больше хранимых процедур, и это наследие длится уже 5 дней. Поместите всю эту информацию в контекст и держитесь подальше от крайних мнений по обе стороны медали.

Скорость не должна быть основным фактором при выборе или в пользу хранимых процедур. Вы можете достичь производительности SP, используя встроенный SQL с Hibernate и другими платформами. Рассмотрите обслуживание и какие другие программы, такие как отчеты, сценарии могут использовать те же самые хранимые процедуры, которые используются вашим приложением. Если для вашего сценария требуется несколько потребителей для одного и того же кода SQL, хранимые процедуры являются хорошим кандидатом, обслуживание будет проще. Если это не так, и вы решили использовать встроенный sql, рассмотрите возможность его использования в файлах конфигурации, чтобы упростить обслуживание.

В конце концов, важно то, что сделает ваш конкретный сценарий успешным для ваших заинтересованных сторон.

Answer 7

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

Основное соотношение - 1/(1-X), где X - доля нагрузки. Это описывает среднюю длину очереди или время ожидания перед обслуживанием. Поэтому сервер, который насыщается, будет очень быстро замедляться при скачках нагрузки.

Сервер, который загружен на 25%, будет иметь среднее время обслуживания 1,333 КБ для некоторой константы К (в общем, К - это время, когда машина выполняет одну транзакцию). На сервере, который загружен на 50%, среднее время обслуживания составляет 2 КБ, а на сервере, загруженном на 90%, среднее время обслуживания составляет 10 КБ. Учитывая, что замедления носят гиперболический характер, часто не требуется большого изменения общей нагрузки, чтобы вызвать значительное снижение времени отклика.

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

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

Обратите внимание, что эта возможность не противоречит возможности неэффективности в коде. Вы можете обнаружить, что способ устранить узкое место - это настроить некоторые из ваших запросов.

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

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

Answer 8

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

Но одна вещь о sprocs, убедитесь, что вы не позволяете ему генерировать динамические операторы SQL

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

Я бы рекомендовал sprocs в основном для обновлений, а затем выбирал операторы. удачи :) 1011

Answer 9

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

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

Как было предложено в одном из ответов, попробуйте проанализировать, используя инструмент профилирования, где проблема - например, вам нужно создавать индексы ...

Приветствия

Answer 10

Вы никогда не можете сказать заранее. Вы должны сделать это и измерить разницу, потому что в 9 из 10 случаев узкое место не там, где вы думаете.

Если вы используете хранимую процедуру, вам не нужно передавать данные. БД обычно медленно выполняют сложные хранимые процедуры [EDIT] [/ EDIT] [EDIT] с циклами, высшей математикой и т. Д. [/ EDIT]. Так что это действительно зависит от того, сколько работы вам нужно сделать, насколько медленной является ваша сеть, как быстро БД выполняет этот конкретный код и т. Д.