Запрос против просмотра

Question

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

Answer 1

Я не могу говорить за все базы данных, но в SQL Server вы не можете индексировать представления, если у вас нет версии Enterprise. Неиндексированное представление может быть значительно хуже с точки зрения производительности, чем запрос, особенно если вы пишете запрос к нему, чтобы добавить некоторые условия условия. Индексированные представления обычно могут работать довольно хорошо. Индексированное представление также может относиться к нескольким полям, которые находятся в разных таблицах, и это может ухудшить производительность по сравнению со специальным запросом. (Это может быть не так, при настройке производительности вы всегда должны проверять свои конкретные обстоятельства.)

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

Представления могут быть более легко поддержаны (просто добавьте эту новую таблицу в объединение, и у всех, кто обращается к финансовым отчетам, она есть), но они намного сложнее настроить производительность. Это отчасти потому, что они имеют тенденцию быть чрезмерно обобщенными и, следовательно, медленнее, чем их аналоги, которые возвращают только необходимый минимум. И да, как сказал Джонатан, вы слишком легко можете объединить представления для отчета в беспорядок, который соединяется с одними и теми же большими таблицами гораздо чаще, чем нужно, и очень медленный.

Два места, где взгляды сияют, хотя: Убедиться, что сложные отношения всегда правильно описаны. Это одна из причин, почему авторы отчетов склоняются к ним. Ограничение доступа к подмножеству записей

Существуют также ограничения на тип запросов, которые можно выполнять для представления, а не для специального запроса или хранимого процесса. Например, вы не можете использовать оператор if (или другой код процедурного типа, такой как цикл), или, как отмечено выше, вы не можете предоставить значения времени выполнения для критериев where.

Одно место, где представления часто значительно медленнее, это когда они вызывают другие представления. Базовые представления должны быть полностью реализованы в некоторых базах данных, и, таким образом, вам может понадобиться вызвать 4 459 203 записей, чтобы увидеть 10, которые вам в конечном счете интересны. Начните разбивать это несколько раз, и это может быть очень медленным, очень быстрым; взгляды, которые называют представлениями, просто плохая практика.

Answer 2

В SQL Server я считаю, что разница в производительности между представлениями и запросами незначительна. Что бы я порекомендовал сделать для повышения производительности, это создать еще одну таблицу, которая будет содержать результаты представления. Возможно, вы могли бы создать промежуточную таблицу, в которой хранятся новые данные, и затем через некоторый интервал можно запустить хранимую процедуру, которая заполняет рабочую таблицу новой информацией. Триггер может быть хорош для этой цели. В зависимости от требований вашего приложения этот дизайн может или не может быть подходящим. Если вы работаете с данными почти в реальном времени, этот подход приведет к проблемам параллелизма ...

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

Answer 3

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

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

Когда-то давным-давно я столкнулся с системой, в которой генератор запросов создал один запрос, который перечислил семнадцать таблиц в одном предложении FROM, включая несколько LEFT OUTER JOIN таблицы с самим собой. И, на самом деле, более тщательное изучение показало, что некоторые из «таблиц» на самом деле были представлениями с несколькими таблицами, и некоторые из них также включали самостоятельные внешние объединения и сами были вовлечены в самостоятельные внешние соединения представления. Сказать " ужасно " - это преуменьшение. Было много возможностей для улучшения производительности этого запроса - устранение ненужных внешних объединений, самостоятельных объединений и так далее. (На самом деле он предшествовал явной нотации соединения в SQL-92 - я уже говорил давно - поэтому синтаксис внешнего соединения был специфичен для СУБД.)

Answer 4

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

HLGEM указывает в своем ответе, что некоторые выпуски SQL Server позволяют вам «индексировать» представления - в этом случае за кулисами SQL Server поддерживает те же структуры, которые лежат в основе таблицы, что делает индексированное представление и таблицу похожи по производительности.

В SQL Server, как правило, можно довольно свободно вкладывать представления, не сталкиваясь с проблемами производительности, но это может усложнить понимание и отладку.

Answer 5

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

Answer 6

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

Упор на мощь и немного ...

Answer 7

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

Answer 8

Если вы имеете в виду производительность сети, то работа из локального кэша (как в случае ADO.Net DataSets) снизит сетевой трафик, но может вызвать проблемы с блокировкой. Просто мысль.