Является ли представление быстрее простого запроса?
Это
select * from myView
быстрее, чем сам запрос для создания представления (для того, чтобы иметь тот же набор результатов):
select * from ([query to create same resultSet as myView])
?
Мне не совсем понятно, использует ли представление какое-то кэширование, что делает его быстрее по сравнению с простым запросом.
17 ответов
Да, представлениям может быть назначен кластерный индекс, и когда они это сделают, они будут хранить временные результаты, которые могут ускорить выполнение запросов.
Обновление: по крайней мере три человека проголосовали против меня на этом. При всем уважении, я думаю, что они просто неправы; Из собственной документации Microsoft очень ясно видно, что Views может повысить производительность.
Во-первых, простые представления расширяются и не вносят непосредственного вклада в повышение производительности - это правда. Однако индексированные представления могут значительно повысить производительность.
Позвольте мне перейти непосредственно к документации:
После создания уникального кластеризованного индекса в представлении результирующий набор представления незамедлительно материализуется и сохраняется в физическом хранилище в базе данных, что экономит накладные расходы на выполнение этой дорогостоящей операции во время выполнения.
Во-вторых, эти индексированные представления могут работать, даже если на них нет прямой ссылки из другого запроса, так как оптимизатор будет использовать их вместо ссылки на таблицу, когда это необходимо.
Опять документация:
Индексированное представление может использоваться при выполнении запроса двумя способами. Запрос может ссылаться на индексированное представление напрямую, или, что более важно, оптимизатор запросов может выбрать представление, если он определит, что представление может заменить часть или весь запрос в плане запроса с наименьшей стоимостью. Во втором случае используется индексированное представление вместо базовых таблиц и их обычных индексов. На представление не нужно ссылаться в запросе, чтобы оптимизатор запросов использовал его во время выполнения запроса. Это позволяет существующим приложениям извлекать выгоду из недавно созданных индексированных представлений без изменения этих приложений.
Эту документацию, а также диаграммы, демонстрирующие улучшения производительности, можно найти здесь.
Обновление 2: ответ подвергся критике на том основании, что именно "индекс" обеспечивает преимущество в производительности, а не "представление". Однако это легко опровергнуть.
Допустим, мы являемся компанией-разработчиком программного обеспечения в маленькой стране; Я буду использовать Литву в качестве примера. Мы продаем программное обеспечение по всему миру и храним наши записи в базе данных SQL Server. Мы очень успешны, и через несколько лет у нас более 1000 000 записей. Однако нам часто приходится сообщать о продажах для целей налогообложения, и мы находим, что мы продали только 100 копий нашего программного обеспечения в нашей стране. Создав индексированное представление только литовских записей, мы получаем нужные нам записи в индексированном кэше, как описано в документации MS. Когда мы запустим наши отчеты о продажах в Литве в 2008 году, наш запрос будет искать по индексу с глубиной всего 7 (Log2(100) с некоторыми неиспользованными листьями). Если бы мы сделали то же самое без ПРОСМОТРА и просто полагаясь на индекс в таблице, нам пришлось бы обходить дерево индексов с глубиной поиска 21!
Ясно, что само представление даст нам преимущество в производительности (в 3 раза) по сравнению с простым использованием только индекса. Я пытался использовать пример из реальной жизни, но вы заметите, что простой список продаж в Литве даст нам еще большее преимущество.
Обратите внимание, что я просто использую прямое b-дерево для моего примера. Хотя я совершенно уверен, что SQL Server использует какой-то вариант b-дерева, я не знаю деталей. Тем не менее, точка имеет место.
Обновление 3: возник вопрос о том, использует ли индексированное представление индекс, размещенный в базовой таблице. То есть, перефразируя: "индексированное представление - это просто эквивалент стандартного индекса, и оно не предлагает ничего нового или уникального для представления". Конечно, если бы это было правдой, то приведенный выше анализ был бы неверным! Позвольте мне привести цитату из документации Microsoft, которая демонстрирует, почему я считаю эту критику недействительной или правдивой:
Использование индексов для повышения производительности запросов - не новая концепция; однако индексированные представления обеспечивают дополнительные преимущества в производительности, которых невозможно достичь с помощью стандартных индексов.
Вместе с приведенной выше цитатой, касающейся сохранения данных в физическом хранилище, и другой информации в документации о том, как создаются индексы в представлениях, я думаю, можно с уверенностью сказать, что индексированное представление - это не просто кэшированный SQL-выбор, который использует Индекс определяется на основной таблице. Таким образом, я продолжаю придерживаться этого ответа.
Вообщем нет. Представления в основном используются для удобства и безопасности, а не для улучшения скорости.
Тем не менее, SQL Server 2000 и выше имеют специальную функцию, называемую индексированными представлениями, которая может значительно повысить производительность, но вы должны создавать индексированные представления, следуя очень специфическому набору рекомендаций.
В Книге Онлайн есть важная ссылка, касающаяся разрешения просмотра.
Вот статья, которая описывает преимущества и создание индексированных представлений:
В течение многих лет Microsoft® SQL Server™ поддерживала возможность создавать виртуальные таблицы, известные как представления. Исторически эти взгляды служили этим основным целям:
Обеспечить механизм безопасности, который ограничивает пользователей определенным подмножеством данных в одной или нескольких базовых таблицах.
Предоставить механизм, который позволяет разработчикам настраивать, как пользователи могут логически просматривать данные, хранящиеся в базовых таблицах.
В SQL Server 2000 функциональность представлений SQL Server была расширена для обеспечения повышения производительности системы. Можно создать уникальный кластеризованный индекс в представлении, а также некластеризованные индексы, чтобы повысить производительность доступа к данным для самых сложных запросов. В SQL Server 2000 и 2005 представление с уникальным кластеризованным индексом называется индексированным представлением.
РЕДАКТИРОВАТЬ: Я был неправ, и вы должны увидеть ответ Маркса выше.
Я не могу говорить по опыту работы с SQL Server, но для большинства баз данных ответ будет отрицательным. Единственное потенциальное преимущество, которое вы получаете, с точки зрения производительности, от использования представления - это то, что оно может потенциально создать некоторые пути доступа на основе запроса. Но основной причиной использования представления является упрощение запроса или стандартизация способа доступа к некоторым данным в таблице. Вообще говоря, вы не получите выигрыша в производительности. Хотя я могу ошибаться.
Я бы придумал немного более сложный пример и сам его посмотрел.
По крайней мере, в SQL Server планы запросов хранятся в кэше планов как для представлений, так и для обычных запросов SQL на основе параметров запросов / представлений. Для обоих они удаляются из кэша, если они не использовались в течение достаточно длительного периода, и для некоторого другого вновь отправленного запроса требуется место. После чего, если выдается тот же запрос, он перекомпилируется и план помещается обратно в кеш. Поэтому нет никакой разницы, учитывая, что вы повторно используете один и тот же SQL-запрос и одно и то же представление с одинаковой частотой.
Очевидно, что в общем случае представление по самой своей природе (то, что кто-то думал, что его следует использовать достаточно часто, чтобы превратить его в представление), как правило, более "повторно" используется, чем любое произвольное выражение SQL.
Определенно, представление лучше, чем вложенный запрос для SQL Server. Не зная точно, почему это лучше (пока я не прочитал пост Марка Бриттингема), я провел несколько тестов и испытал почти шокирующее повышение производительности при использовании представления вместо вложенного запроса. После выполнения каждой версии запроса несколько сотен раз подряд просмотр версии запроса выполнялся в два раза быстрее. Я бы сказал, что для меня достаточно доказательств.
Это может быть быстрее, если вы создадите материализованное представление (с привязкой схемы). Нематериализованные представления выполняются так же, как и обычный запрос.
Насколько я понимаю, некоторое время назад представление было бы быстрее, потому что SQL Server мог сохранить план выполнения, а затем просто использовать его вместо того, чтобы пытаться понять его на лету. Я думаю, что прирост производительности в настоящее время, вероятно, не так велик, как это было раньше, но я должен был бы предположить, что будет некоторое незначительное улучшение, чтобы использовать представление.
Я ожидаю, что два запроса будут выполняться одинаково. Представление - это не что иное, как сохраненное определение запроса, для представления нет кэширования или хранения данных. Оптимизатор эффективно превратит ваш первый запрос во второй, когда вы его запустите.
Должен быть некоторый тривиальный выигрыш в хранении плана выполнения, но он будет незначительным.
Все зависит от ситуации. Индексированные представления MS SQL выполняются быстрее, чем обычные представления или запросы, но индексированные представления нельзя использовать в зеркальной среде базы данных (MS SQL).
Представление в любом виде цикла вызовет серьезное замедление, поскольку представление заполняется каждый раз, когда оно вызывается в цикле. То же, что и запрос. В этой ситуации временная таблица, использующая # или @ для хранения ваших данных в цикле, работает быстрее, чем представление или запрос.
Так что все зависит от ситуации.
В этом нет никакой практической разницы, и если вы прочитаете BOL, вы обнаружите, что ваш простой SQL SELECT * FROM X использует преимущества кэширования плана и т. Д.
Выбор из вида или из таблицы не будет иметь особого смысла.
Конечно, если в представлении нет ненужных объединений, полей и т. Д. Вы можете проверить план выполнения ваших запросов, объединений и индексов, используемых для повышения производительности представления.
Вы даже можете создать индекс по представлениям для более быстрого поиска. http://technet.microsoft.com/en-us/library/cc917715.aspx
Но если вы выполняете поиск как "%...%", то движок sql не получит выгоды от индексации по текстовому столбцу. Если вы сможете заставить своих пользователей выполнять поиск вроде "...%", это будет быстро
см. ответ на форумах asp: https://forums.asp.net/t/1697933.aspx?Which+is+faster+when+using+SELECT+query+VIEW+or+Table+
Вопреки всем ожиданиям, в некоторых случаях просмотры идут намного медленнее.
Я обнаружил это недавно, когда у меня были проблемы с данными, которые были извлечены из Oracle, которые нужно было преобразовать в другой формат. Может быть, 20k исходных строк. Небольшой стол. Для этого мы импортировали данные оракула в максимально неизменном виде в таблицу, а затем использовали представления для извлечения данных. У нас были вторичные взгляды, основанные на этих взглядах. Может быть, 3-4 уровня просмотров.
Один из последних запросов, который извлекает примерно 200 строк, займет более 45 минут! Этот запрос был основан на каскаде просмотров. Может быть, на 3-4 уровня.
Я мог бы взять каждое из рассматриваемых представлений, вставить его sql в один вложенный запрос и выполнить его за пару секунд.
Мы даже обнаружили, что можем даже записать каждое представление во временную таблицу и запросить ее вместо представления, и это все еще было намного быстрее, чем просто использование вложенных представлений.
Еще более странным было то, что производительность была хорошей, пока мы не достигли некоторого предела исходных строк, загружаемых в базу данных, а производительность просто упала со скалы в течение пары дней - все, что потребовалось, - это еще несколько исходных строк.
Итак, использование запросов, которые извлекают из представлений, которые извлекают из представлений, намного медленнее, чем вложенный запрос, что для меня не имеет смысла.
На мой взгляд, использование представления немного быстрее, чем обычный запрос. Моя хранимая процедура занимала около 25 минут (работа с другими большими наборами записей и несколькими объединениями), и после использования представления (некластеризованного) производительность была немного выше, но не существенной. Мне пришлось использовать некоторые другие методы / методы оптимизации запросов, чтобы сделать это кардинальным изменением.
Цель представления - использовать запрос снова и снова. Для этого SQL Server, Oracle и т. Д. Обычно предоставляют "кэшированную" или "скомпилированную" версию вашего представления, что повышает его производительность. В целом, это должно выполняться лучше, чем "простой" запрос, хотя, если запрос действительно очень прост, преимущества могут быть незначительными.
Теперь, если вы делаете сложный запрос, создайте представление.
Представление № - это всего лишь короткая форма вашего фактического длинного запроса sql. Но да, вы можете сказать, что фактический запрос быстрее, чем просмотр команды/запроса.
Первый запрос просмотра будет преобразован в простой запрос, а затем будет выполнен, поэтому запрос просмотра займет больше времени для выполнения, чем простой запрос.
Вы можете использовать sql-представления, когда используете соединения ч/б с несколькими таблицами, чтобы снова и снова использовать сложный запрос простыми способами.
Я наткнулся на эту ветку и просто хотел поделиться этим постом от Брента Озара в качестве того, что следует учитывать при использовании групп доступности.