Представление SQL Server 2005 против материализованного представления против хранимой процедуры
-
06-07-2019 - |
Вопрос
Если у меня есть таблица, содержащая десятки тысяч записей учетных записей для нескольких местоположений.
Есть ли разница в скорости, если я запрашиваю представление, которое выбирает все учетные записи для определенного местоположения и хранимую процедуру с тем же оператором SQL?
РЕДАКТИРОВАТЬ: я столкнулся с этим материализованным представлением. Кажется, что это всегда будет использоваться.
Когда вы хотите использовать процедуру хранения, представление и материализованное представление? Какие плюсы и минусы вы хотите иметь в виду при принятии этого решения?
Решение
Краткий ответ: «Это зависит»
Более длинный ответ: " зависит от формы запроса "
Как и в случае с любым вопросом о производительности в SQL Server (что лучше: x против y), правильного ответа нет. В случае представлений и sprocs, нет никакого способа надежно предсказать, что будет (если есть) быстрее, если не профилировать запрос.
Я видел, как оба быстрее, и все сводится к тому, как использовалось представление и является ли оно частью более крупного запроса. Я также видел, что представления замедляют запросы, потому что они могут скрыть большую сложность, которая на самом деле не нужна запросу, использующему представление.
Вам нужно оценить, чего вы пытаетесь достичь: если все, что вы делаете, - это хотите получить доступ к строкам таблицы и не хотите использовать вывод как часть другого запроса, я бы выберите хранимую процедуру, особенно если запрос к таблице будет принимать предложение WHERE. Р>
Откуда будет вызываться запрос? Другая часть SQL? Какой-то фреймворк для приложений? Пользовательский слой доступа к данным? Стоит подумать, как вызывающий код соберет запрос, так как это может повлиять на то, как SQL Server завершит кеширование и повторное использование плана выполнения. Если он просто скрепит кучу динамического SQL, производительность может немного снизиться, поскольку SQL Server может понадобиться каждый раз перестраивать план запроса; так что в этом случае sproc имеет преимущество с кэшированным планом. Если уровень доступа интеллектуален и выполняет параметризованный динамический SQL, в нем может быть не так много.
Вывод: поймите, чего вы хотите достичь. Затем профиль, настройте, настройте и повторяйте до тех пор, пока не будете удовлетворены.
Другие советы
Представление и хранимая процедура скомпилированы в базу данных, поэтому они работают быстрее, чем прямой запрос, разница в скорости между ними появляется, когда вам нужны динамические параметры. Взгляды просто не принимают их. Р>
Каждый из них имеет свое специфическое использование. Представления могут использоваться в других запросах или представлениях. Хранимые процедуры могут выполняться только. Но на ваш вопрос с одинаковыми SELECT * FROM они имеют одинаковую скорость.
Да и нет. Р>
Представление - это определение запроса, которое при использовании заменяется на месте и компилируется в запрос, который ссылается на представление. Это означает, что фактическое выполнение зависит от запроса , который ссылается на представление . Если запрос является простым SELECT * FROM view
, то это будет в значительной степени тот же план выполнения, что и эквивалентная процедура. Однако если запрос SELECT onefield FROM view
, запрос значительно отличается. Не существует эквивалентной процедуры, и этот запрос может работать значительно лучше из-за сокращенного списка проекций.
Существуют также огромные различия в удобстве использования. Хранимая процедура может быть выполнена только. Представление может быть выбрано из и и использоваться с множеством других операторов, таких как объединения, подзапросы и т. П.
Учитывая гораздо лучшую гибкость представлений, если никакой другой фактор не играет роли, тогда процедура имеет смысл, только если у вас есть параметры, поскольку представления не могут иметь параметры.
Ответы на этот Post предоставит полезную информацию об индексированных (материализованных) представлениях в SQL Server.
Я также видел, что каждый из них был быстрее другого, в зависимости от контекста.
Общее правило, которому я следую, таково: если представление имеет комплекс WHERE, зависит от других умеренно сложных представлений или является результатом UNION [ALL], то почти наверняка SQL S. не сможет правильно выполнить распространять условия WHERE, применяемые к представлению, вплоть до отдельных таблиц, поэтому в один прекрасный момент вы начнете получать сканирование таблиц (если это не материализованное представление), или ваши планы выполнения будут намного более сложными (и медленными), чем те, которые они может быть.
В этих случаях лучше пойти на процедуру. И, как говорили другие, всегда профиль!