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

Question

Что быстрее в SQL Server 2005/2008, хранимая процедура или Представление?

Редактировать: Как многие из вас отмечали, я выражаюсь слишком расплывчато.Позвольте мне попытаться выразиться немного конкретнее.
Я хотел знать разницу в производительности для конкретного запроса в представлении по сравнению с точно таким же запросом внутри хранимой процедуры.(Я по-прежнему ценю все ответы, которые указывают на их различные возможности)

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

Answer 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, то вторая ссылка выше - хорошее место для начала.

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

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

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

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

У кого-нибудь есть какие-нибудь мысли?