Производительность SQL-сервера: что происходит быстрее, хранимая процедура или представление?

Ответ 1

Хранимые процедуры (SP) и SQL-представления - это разные "звери", как указано несколько раз в этом сообщении.

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

Вид ограничен тем, что может быть выражено в одном выражении SELECT (ну, возможно, с CTE и несколькими другими трюками), но в целом представление привязано к декларативным формам запросов, Хранимая процедура с другой стороны может использовать различные конструктивные конструкции процедурных типов (а также декларативные), и, как результат, используя SP, можно создать ручной инструмент для решения данного запроса который может быть более эффективным, чем мог бы сделать оптимизатор запросов SQL-Server (на основе единого декларативного запроса). В этих случаях SP могут быть намного быстрее (но будьте осторожны... оптимизатор довольно умный, и не требуется много сделать SP намного медленнее, чем эквивалентное представление.)

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

Ответ 2

К сожалению, это не тот тип зверя.

Хранимая процедура представляет собой набор операторов T-SQL и CAN возвращает данные. Он может выполнять все виды логики и не обязательно возвращает данные в наборе результатов.

Представление представляет собой представление данных. Он в основном используется как абстракция одной или нескольких таблиц с базовыми объединениями. Это всегда набор результатов из нуля, одной или нескольких строк.

Я подозреваю, что ваш вопрос более похож на:

Что происходит быстрее: SELECT ing из представления или эквивалентный оператор SELECT в хранимой процедуре, учитывая те же базовые таблицы, в которых выполняются объединения с теми же предложениями?

Ответ 3

На самом деле это не ответственно, потому что ответ будет справедливым во всех случаях. Однако, как общий ответ для конкретной реализации SQL Server...

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

Представление - это, по сути, сохраненный оператор SQL.

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

Ссылка на эти ссылки, подтверждающие мой ответ.

http://www.sql-server-performance.com/tips/stored_procedures_p1.aspx

http://msdn.microsoft.com/en-us/library/ms998577.aspx

Кроме того, если вы ищете все способы оптимизации производительности на SQL Server, вторая ссылка выше - это хорошее место для начала.

Ответ 4

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

Ответ 5

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

Но вы не можете использовать результаты хранимой процедуры в запросах выбора или присоединения.

Если вы не хотите использовать набор результатов в другом запросе, лучше использовать SP.

Остальные детали и различия упоминаются людьми на этом форуме и в других местах.

Ответ 6

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

Я предполагаю, что я говорю, вместо sp vs views, думаю sp и views:)

Ответ 7

Сохраненные процедуры и представления различны и имеют разные цели. Я рассматриваю представления как законченные запросы. Я смотрю хранимые процедуры как модули кода.

Например, скажем, у вас есть таблица с именем tblEmployees с этими двумя столбцами (среди прочих): DateOfBirth и MaleFemale.

Вид, называемый viewEmployeesMale, который отфильтровывает только мужчин-сотрудников, может быть очень полезен. Представление, называемое viewEmployeesFemale, также очень полезно. Оба эти представления самоописаны и очень интуитивно понятны.

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

Ответ 8

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

• SP будет поддерживать упорядочение набора результатов; то есть, включая инструкцию ORDER BY. Вы не можете сделать это в представлении.
• SP полностью скомпилирован и требует только exec для его вызова. Для просмотра все еще требуется SELECT * FROM view, чтобы вызвать его; то есть выбор на скомпилированном элементе в представлении.

Ответ 9

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

У меня есть представление в базе данных "A", которое объединяет 5 таблиц в отдельной базе данных (db "B" ). Если я прикрепляю к db "A" в SSMS и SELECT * из представления, для возврата 250000 строк требуется > 3 минуты. Если я беру инструкцию select на странице дизайна представления и выполняю ее непосредственно в SSMS, она принимает < 25 секунд. Помещение того же оператора select в хранимую процедуру дает такую ​​же производительность при выполнении этой процедуры.

Без каких-либо наблюдений за абсолютной производительностью (db "B" - это база данных AX, которую нам нельзя трогать!), я по-прежнему абсолютно убежден, что в этом случае использование SP на порядок быстрее, чем использование a View для получения одних и тех же данных, и это относится ко многим другим аналогичным представлениям в данном конкретном случае.

Я не думаю, что это связано с созданием соединения с другим db, если только с помощью представления он каким-то образом никогда не может кэшировать соединение, в то время как выбор делает, потому что я могу переключаться между двумя выбранными в той же SSMS окна, и производительность каждого запроса остается непротиворечивой. Кроме того, если я подключаюсь напрямую к db "B" и запускаю select без dbname.dbo.... refs, он принимает то же время.

Любые мысли кто-нибудь?

Ответ 10

Нашел подробный анализ производительности: https://www.scarydba.com/2016/11/01/stored-procedures-not-faster-views/

Сравнение времени компиляции:

Существует разница во времени компиляции между самим представлением и хранимыми процедурами (они были почти идентичны). Давайте посмотрим на производительность за несколько тысяч казней:

Просмотр AVG: 210.431431431431

Сохраненный процесс с просмотром AVG: 190.641641641642

Сохраненный Proc AVG: 200.171171171171

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

Как насчет времени выполнения, включая время компиляции, так как есть разница:

Продолжительность запроса View AVG: 10089.3226452906

Сохраненный Proc AVG: 9314.38877755511

Сохраненный процесс с просмотром AVG: 9938.05410821643

Вывод:

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