Выполняют ли хранимые процедуры SQL Server лучше в сетевых кластерах?

Question

Из того, что я прочитал, по-видимому, существуют незначительные преимущества в производительности с использованием хранимых процедур, а просто для создания команд на C# и их прямого вызова в коде программы, по крайней мере, когда речь заходит о машинах, которые используют серверную программу и движок db (и когда процедуры просты). Большинство людей, похоже, считают, что это «проблема предпочтений», и добавить несколько других незначительных преимуществ, чтобы оправдать их дело.

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

Если я не ошибаюсь, на ферме серверов не будет ли выгружать обработку на некоторые потоки процессора из основного серверного приложения, а будет ли первичная обработка на процессоре сервера db-сервера? Или это уже сделано на процессоре db engine в любом случае, когда библиотеки C# «строят» информацию для процесса обработки db?

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

Это правда?

Answer 1

Производительность от хранимой процедуры (в отличие от Dapper или OR/M, такой как Entity Framework) может варьироваться от почти одинакового до очень заметного улучшения производительности. Я не думаю, что на ваш вопрос можно ответить без просмотра кода, который будет переведен в хранимую процедуру.

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

Answer 2

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

Я не уверен в эффекте, если SP более сложный, потому что это будет зависеть от запроса.

Answer 3

Более важным преимуществом SP является то, что все данные хранятся в СУБД вместо отправки назад и вперед клиенту. Если вы имеете дело с большим объемом данных, то преимущество становится более очевидным. Разница возрастает, если ваша БД находится на другой машине и даже больше, если соединение между ними медленное. Напротив, вы должны учитывать, что SP обычно не компилируется в машинный код, поэтому, если SP реализует очень сложную логику, он может быстрее реализовать логику на клиенте. Тогда вы также должны учитывать, что перемещение бизнес-логики на сервер не так хорошо для обслуживания кода, вы можете добавить технологию дебетования, реализующую в БД, что-то, что должно быть в вашем клиентском коде. Итак, решение не действует в течение всех сезонов, но обычно хорошо написанный SP быстрее, чем тот же код, который выполняется на клиенте.

Answer 4

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

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