Представление SQL Server 2005 против материализованного представления против хранимой процедуры

Question

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

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

РЕДАКТИРОВАТЬ: я столкнулся с этим материализованным представлением. Кажется, это всегда будет использоваться.

Когда вы хотите использовать процедуру хранения, представление и материализованное представление? Какие плюсы и минусы вы хотите иметь в виду при принятии этого решения?

Answer 1

Краткий ответ: "Это зависит"

Более длинный ответ: "Это зависит от формы запроса"

Как и в случае любого вопроса о производительности в SQL Server (что лучше: x против y), правильного ответа нет. В случае представлений и sprocs, нет никакого способа надежно предсказать, что будет (если есть) быстрее, если не профилировать запрос.

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

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

Откуда будет вызываться запрос? Другая часть SQL? Некоторые прикладные рамки? Пользовательский слой доступа к данным? Стоит подумать, как вызывающий код соберет запрос, так как это может повлиять на то, как SQL Server завершит кеширование и повторное использование плана выполнения. Если он просто скрепит кучу динамического SQL, производительность может немного снизиться, поскольку SQL Server может понадобиться каждый раз перестраивать план запроса; так что в этом случае sproc имеет преимущество с кэшированным планом. Если уровень доступа интеллектуален и выполняет параметризованный динамический SQL, в нем может быть не так много.

Вывод: поймите, чего вы хотите достичь. Затем выполните профиль, настройте, настройте и повторяйте до тех пор, пока не будете удовлетворены.

Answer 2

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

Каждый из них имеет свое специфическое использование. Представления могут использоваться в других запросах или представлениях. Хранимые процедуры могут выполняться только. Но на твой вопрос с одинаковыми SELECT * FROM они имеют одинаковую скорость.

Answer 3

Да и нет.

Представление - это определение запроса, которое в основном заменяется на месте при использовании, и оно компилируется в запрос, который ссылается на представление. Это означает, что фактическое выполнение зависит от запроса , который ссылается на представление . Если запрос прямой SELECT * FROM view, то это будет в значительной степени тот же план выполнения, что и эквивалентная процедура. Однако, если запрос SELECT onefield FROM view, запрос значительно отличается. Не существует эквивалентной процедуры, и этот запрос может работать значительно лучше из-за сокращенного списка проекций.

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

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

Answer 4

Я также видел, что каждый из них был быстрее другого, в зависимости от контекста.

Общее правило, которому я следую, таково: если представление имеет комплекс WHERE, зависит от других умеренно сложных представлений или является результатом UNION [ALL], то почти наверняка SQL S. не сможет правильно выполнить распространять условия WHERE, применяемые к представлению, вплоть до отдельных таблиц, поэтому в один прекрасный момент вы начнете получать сканирование таблиц (если это не материализованное представление), или ваши планы выполнения будут намного более сложными (и медленными), чем те, которые они может быть.

В этих случаях лучше пойти на процедуру. И, как говорили другие, всегда в профиле!

Answer 5

Ответы на эту публикацию предоставят полезную информацию об индексированных (материализованных) представлениях в SQL Server.