Влияет ли представление базы данных на производительность запросов?

Question

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

Answer 1

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

Answer 2

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

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

Answer 3

Это зависит от СУБД, но обычно оптимизации не происходит, и это просто удобный способ упростить запросы. Однако в некоторых системах баз данных используются «материализованные представления», в которых используется механизм кэширования.

Answer 4

Обычно представление - это просто способ создать общее сокращение для определения часто используемых наборов результатов.

Однако есть и обратная сторона. Соблазн состоит в том, чтобы добавить в каждый столбец, который, по вашему мнению, вам может понадобиться где-то, когда вы захотите использовать представление. Итак, ЯГНИ нарушено. Не только столбцы, но иногда дополнительные внешние соединения прикрепляются «на всякий случай». Таким образом, закрывающие индексы могут не охватывать больше, и план запроса может усложниться (и упасть в эффективности).

YAGNI является критически важной концепцией в дизайне SQL.

Answer 5

Я знаю, что это старая тема. Обсуждение это хорошо, но я хочу добавить еще одну мысль. Производительность также зависит от того, что вы используете для получения данных. Например, если вы работаете во внешнем интерфейсе с чем-то вроде Microsoft Access, вы можете определенно повысить производительность для некоторых сложных запросов с помощью представления. Это связано с тем, что Access не всегда извлекает данные из SQL-сервера, как хотелось бы - в некоторых случаях он перетаскивает целые таблицы, а затем пытается оттуда обрабатывать локально! Не так, если вы используете представление.

Answer 6

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

Но: возможны крайние случаи, и вам следует протестировать свой код. Все современные системы RDBMS имеют инструменты, которые позволят вам видеть планы запросов и контролировать выполнение. Не верьте моему (или чьему-либо еще) слову за это, когда вы можете иметь точные данные у вас под рукой.

Answer 7

Да, во всех современных СУБД (MSSQL после 2005 года и т. Д.) Планы запросов представления кэшируются, что устраняет накладные расходы при планировании запроса и повышает производительность по сравнению с тем же SQL, выполняемым в потоке. До этого (и это относится и к параметризованным SQL / подготовленным выражениям) люди правильно думали, что хранимые процедуры выполняются лучше.

Многие все еще держатся за это сегодня, что делает его современным мифом о БД. С тех пор, как Views / PS разработали кэшированное планирование запросов SP, они были почти равны.