Представление быстрее, чем простой запрос?
Это
select * from myView
быстрее, чем сам запрос, чтобы создать представление (чтобы иметь тот же набор результатов):
select * from ([query to create same resultSet as myView])
?
Мне не совсем понятно, использует ли представление какое-то кеширование, что делает его быстрее по сравнению с простым запросом.
Ответы 16
да, представлениям может быть назначен кластерный индекс, и, когда они это делают, они будут хранить временные результаты, которые могут ускорить результирующие запросы.
Обновление: по крайней мере три человека проголосовали против меня по этому поводу. При всем уважении, я считаю, что они ошибаются; Собственная документация Microsoft ясно дает понять, что представления могут улучшить производительность.
Во-первых, простые представления расширяются на месте и поэтому напрямую не способствуют повышению производительности - это действительно так. Индексированные представления Тем не мение, могут повысить производительность резко.
Перейдем непосредственно к документации:
After a unique clustered index is created on the view, the view's result set is materialized immediately and persisted in physical storage in the database, saving the overhead of performing this costly operation at execution time.
Во-вторых, эти индексированные представления могут работать с даже если на них напрямую не ссылается другой запрос, поскольку оптимизатор будет использовать их вместо ссылки на таблицу, когда это необходимо.
Опять же, документация:
The indexed view can be used in a query execution in two ways. The query can reference the indexed view directly, or, more importantly, the query optimizer can select the view if it determines that the view can be substituted for some or all of the query in the lowest-cost query plan. In the second case, the indexed view is used instead of the underlying tables and their ordinary indexes. The view does not need to be referenced in the query for the query optimizer to use it during query execution. This allows existing applications to benefit from the newly created indexed views without changing those applications.
Эту документацию, а также диаграммы, демонстрирующие улучшения производительности, можно найти здесь.
Обновление 2: ответ был подвергнут критике на том основании, что именно «индекс» обеспечивает преимущество в производительности, а не «представление». Однако это легко опровергнуть.
Допустим, мы являемся софтверной компанией в маленькой стране; Я использую Литву в качестве примера. Мы продаем программное обеспечение по всему миру и храним наши записи в базе данных SQL Server. Мы очень успешны, и поэтому за несколько лет у нас есть более 1 000 000 записей. Однако нам часто требуется сообщать о продажах для целей налогообложения, и мы обнаруживаем, что продали только 100 копий нашего программного обеспечения в нашей стране. Создавая индексированное представление только для литовских записей, мы можем хранить нужные нам записи в индексированном кэше, как описано в документации MS. Когда мы запускаем наши отчеты о продажах в Литве в 2008 году, наш запрос будет искать по индексу с глубиной всего 7 (Log2 (100) с некоторыми неиспользованными листами). Если бы мы сделали то же самое без VIEW и просто полагались бы на индекс в таблице, нам пришлось бы пройти по дереву индексов с глубиной поиска 21!
Ясно, что само представление даст нам преимущество в производительности (в 3 раза) по сравнению с простым использованием одного индекса. Я попытался использовать реальный пример, но вы заметите, что простой список литовских продаж даст нам еще большее преимущество.
Обратите внимание, что в моем примере я просто использую прямое b-дерево. Хотя я вполне уверен, что SQL Server использует какой-то вариант b-дерева, я не знаю подробностей. Тем не менее, суть сохраняется.
Обновление 3: Возник вопрос о том, использует ли индексированное представление только индекс, размещенный в базовой таблице. То есть, перефразируя: «индексированное представление - это просто эквивалент стандартного индекса, и оно не предлагает ничего нового или уникального для представления». Если бы это было правдой, конечно, то приведенный выше анализ был бы неверен! Позвольте мне привести цитату из документации Microsoft, которая демонстрирует, почему я думаю, что эта критика неверна или верна:
Using indexes to improve query performance is not a new concept; however, indexed views provide additional performance benefits that cannot be achieved using standard indexes.
Вместе с приведенной выше цитатой относительно постоянства данных в физическом хранилище и другой информацией в документации о том, как создаются индексы в представлениях, я думаю, можно с уверенностью сказать, что индексированное представление - это нет, просто кэшированный SQL Select, который, как правило, использует индекс, определенный в основной таблице. Таким образом, я продолжаю придерживаться этого ответа.
Точка зрения Райана верна: цель заключается не в улучшении производительности (несмотря на небольшое улучшение, которое я указываю). Это необходимо для упрощения других запросов или стандартизации доступа к данным.
Планы запросов хранятся в кэше планов как для представлений, так и для обычных SQL-запросов на основе параметров запроса / представления. Для обоих они удаляются из кеша, когда они не использовались в течение достаточно длительного периода времени и требуется пространство. После чего, если будет выдан такой же запрос, он будет перекомпилирован.
Люди - RTFM; как сказал Чарльз - обычные SQL-запросы получают кэширование планов.
Да, индексированные представления могут значительно повысить производительность. Но индексированные представления - это не просто «представления», и, вообще говоря, нормальное «представление» не быстрее, чем связанные с ними запросы.
Брэд, я думаю, что причина того, что многие люди не используют индексированные представления, заключается в том, что они просто не знают о них. Обидно: они очень полезны! Так что технически вы правы. Тем не менее, я думаю, что мой ответ хороший, особенно с учетом роли SO как среды взаимопомощи.
@Mark, индексированное представление ДЕЙСТВИТЕЛЬНО увеличивает производительность, но НЕ потому, что это представление. Это увеличивает производительность, потому что индексируется. Фактически, если существует индексированное представление, вы получаете такое же повышение производительности от обычного оператора SQL, который может использовать этот индекс, даже если он ссылается на таблицу, а не на представление.
т.е. не «представление» в индексированном представлении обеспечивает повышенную производительность, а «индекс».
Чарльз - имейте в виду также кеширование данных. Например, если я индексирую набор полей в таблице, я получаю преимущество. Если я создаю Вид с подмножеством набора данных, а затем создаю индекс, я получаю преимущество как индекса, так и представления - потому что индекс теперь меньше.
@Charles - не имеет значения, является ли это индекс, того факта, что представление может использовать индекс, а необработанный запрос не может.
/ аплодируйте @Mark за то, что он стоял на своем и рационально отстаивал этот вопрос
@Mark, на самом деле, индекс не меньше при создании в представлении, чем при создании самого по себе.
@annkata, это, к сожалению, именно моя точка зрения. необработанный запрос МОЖЕТ получить доступ к любому индексу, даже созданному с помощью индексированного представления, и использовать его, как и представление.
@Mark, "индексированное представление" - это просто сохраненный SQL (представление) и индекс (как определено оператором создания индекса), который зависит только от столбцов, определенных в индексе, полностью независимый от представления, для которого он был определен. . Вы можете эквивалентно создать индекс и неиндексированное представление
Спасибо, аннаката - я не против отступить или признать свою неправоту. Мне пришлось сделать это достаточно, чтобы я хорошо тренировался!
Чарльз. Можете ли вы предоставить документацию, подтверждающую ваше утверждение, что View использует индекс только для базовой таблицы? Насколько я понимаю, индекс создается для подмножества данных, извлеченных для представления - это мое объяснение.
Я обновил ответ, чтобы отразить некоторые дополнительные исследования. Извини, Чарльз, я думаю, совершенно очевидно, что ты ошибаешься в этом вопросе, поэтому я продолжаю придерживаться своего ответа.
@Mark, нет проблем, извините, если я неправильно понял ваш комментарий, но если я вас правильно прочитал, вы меня неправильно поняли. Я не сказал, что он ТОЛЬКО использует индекс в базовой таблице, я сказал, что индекс, который вы создаете, является независимым объектом от представления и может использоваться ЛЮБЫМ запросом на Tbl.
@Mark, вы можете проверить это на себе, создать индексированное представление, запустить запрос, используя представление, и изучить план выполнения запроса. Он четко покажет, какой индекс используется. Затем выполните тот же запрос с использованием Direct SQL из таблицы, а не из представления. План выполнения будет таким же, но с тем же индексом.
т.е. выберите * из представления, где [Столбцы, определенные в индексе в представлении] - чтобы сделать запрос настраиваемым и разрешить использование индекса. Затем выберите * Из таблицы, где [здесь те же предикаты, что и выше] Планы выполнения будут идентичными. с идентичной производительностью
@ Чарльз, думаю, мы согласны. Фактически, это, вероятно, является основанием для утверждения MS о том, что индексированное «представление» будет использоваться запросами, которые даже не используют само представление. Хороший улов, и вы правы - я вас неправильно истолковал. Простите!
Но если представление не существует и, следовательно, индекс не существует, необработанный запрос не сможет его использовать. И какие БД могут разделять этот индекс?
@annakata, Моя точка зрения заключалась в том, что вы можете создать индекс независимо, «Создать индекс MyIndexname On TableName (ColumnA, ColumnB и т. д.)» и получить точно такое же увеличение производительности для ВСЕХ запросов SQL без создания представления
@Mark, Отлично .. Спасибо за то, что потратили время и силы на внимательное "прослушивание".
@Annakata, ЕДИНСТВЕННАЯ причина для создания индексированного представления заключается в том, что вам нужно повысить производительность ВТОРОГО КЛАСТЕРИРОВАННОГО индекса и вы не можете заменить существующий кластерный индекс (в таблице) «правильным» кластеризованным индексом для запроса, который вы пытаетесь выполнить. мелодия. не ...
Поскольку таблица может иметь только один индекс clusterdee, и вы МОЖЕТЕ создать отдельный кластеризованный индекс для представления (поскольку поля в кластеризованном индексе независимо сохраняются на страницах индекса), это обман (работа вокруг?), позволяет получить ДВА кластеризованных индекса в одной таблице.
AnnaKata - о полностью другой теме ... Вы поклонник Portal - игры? Я спрашиваю об этом из-за изображения / значка вашего профиля.
@MarkBrittingham Если то, что вы говорите, правда, и созданный индекс каким-то образом ограничен только данными, присутствующими в представлении в данный момент, воссоздается ли структура индекса каждый раз, когда вы вставляете или удаляете данные?
Ничего себе спорный ответ! Я согласен, что это правильно, но это можно улучшить, добавив примечание о потенциальном негативном влиянии индексированных представлений на производительность. Я считаю, что у них есть все недостатки обычных индексов (требования к пространству и снижение производительности вставки), а также некоторые неожиданные действия с привязкой к схеме (это усложняет изменение базовых таблиц)
Хороший пример литовского рынка и ответил на мои сомнения по поводу просмотра и таблицы.
Это, вероятно, следует читать: "Да, если, вы можете индексировать представление ..." Это довольно серьезная оговорка. Не все представления может индексируются.
Хороший пример, но индексированные представления достаточно дороги с точки зрения реальных денег, они доступны только в версии Enterprise?
@MarkBrittingham Для демонстрации использования Index Views и их эффекта для подтверждения ваших слов вы можете включить результаты из simple-talk.com/sql/learn-sql-server/… Также стоит упомянуть, что Index Views иногда может быть контрпродуктивным: sqlblog.com/blogs/alexander_kuznetsov/archive/2009/06/02/…
Мастерски объяснил и защитил @MarkBrittingham
Единственная жалоба на StackOverflow заключается в том, что вы можете проголосовать только один раз. Я обсуждал этот момент в течение многих лет, и независимо от того, сколько тестов вы запускаете или сколько запросов вы сравниваете, многие отказываются верить в это - это все равно, что обсуждать изменение климата с кем-то, кто не верит в науку. Если один запрос выполняется за 1 минуту с использованием подзапросов, а другой - менее чем за 1 секунду с использованием представлений, дискуссия окончена. Спасибо @MarkBrittingham за то, что так хорошо сформулировали моменты!
Я уверен, что использование представлений будет опережать использование запросов только в большинстве ваших тестовых сценариев. Но правильный ответ - «(скорее всего)», а не однозначное «да»! Данные должны собираться, когда вы используете представление хотя бы один раз после каждого обновления таблицы (особенно, когда вы нажимаете записи, которые находятся в представлении). Это запустит запрос к таблице для представления, а затем будет фактический запрос в представлении. В худшем случае эти два запроса могут быть медленнее, чем один запрос в обновленной таблице.
Сегодня я столкнулся с проблемой, когда выполняю запрос к такому простому представлению, как SELECT * FROM MyView. Бег длился 2 минуты 34 секунды. Если я запускаю базовый запрос представления, он выполняется за 2 секунды. Другой более сложный запрос, который ссылается на представление, также выполняется медленно, но когда я заменяю указанное представление в запросе вложенным выбором, он выполняется намного быстрее. Как вы думаете, почему это происходит? По моему общему опыту, использование представлений упрощает чтение или повторное использование запросов, но не повышает производительность.
Документ Microsoft отключен (microsoft.com/technet/prodtechnol/sql/2005/impprfiv.mspx)
@MarkBrittingham Я предполагаю, что все, что вы сказали, верно и для базы данных оракула. Это? Потому что другие ответы кажутся противоречащими вашему.
Это может ускорить рабочие нагрузки с интенсивным чтением, но также может замедлить рабочие нагрузки с интенсивной записью (хотя, вероятно, это редкий случай). Как всегда, сравните свой конкретный случай.
Это хорошая информация. Может быть, упрощено как «Представления позволяют создавать кластерные индексы для нескольких таблиц».
Обновлено: я был неправ, и вы должны увидеть Отмечает ответ выше.
Я не могу говорить по опыту с SQL Server, но для большинства баз данных ответ будет отрицательным. Единственное потенциальное преимущество, которое вы получаете с точки зрения производительности, от использования представления, заключается в том, что оно потенциально может создавать некоторые пути доступа на основе запроса. Но основная причина использования представления - упростить запрос или стандартизировать способ доступа к некоторым данным в таблице. Вообще говоря, вы не получите выигрыша в производительности. Хотя я могу ошибаться.
Я бы предложил более сложный пример и успел бы увидеть его самому.
еще одна причина использования представлений - это помощь в управлении доступом в ролевых моделях.
Вы ошибаетесь насчет улучшений производительности. Я не объяснил достаточно, чтобы убедить некоторых людей в моем первоначальном комментарии, но у MS есть явная документация о том, как использовать представления для повышения производительности. См. Мой ответ (который сейчас сильно отклонен) ниже.
Это может быть быстрее, если вы создадите материализованное представление (со схемой привязки). Нематериализованные представления выполняются так же, как и обычный запрос.
schemabinding имеет мало общего с производительностью, он связывает схему представления с базовой таблицей, поэтому она остается синхронизированной и является предварительным требованием для индексированных представлений.
материализованное представление и представление - это одно и то же? Я думаю, что это так, но материализованное представление хранится на диске, а представление может быть просто в памяти, верно?
Я понимаю, что некоторое время назад представление было бы быстрее, потому что SQL Server мог хранить план выполнения, а затем просто использовать его вместо того, чтобы пытаться выяснить его на лету. Я думаю, что прирост производительности в настоящее время, вероятно, не так велик, как когда-то, но я должен предположить, что при использовании представления будет некоторое незначительное улучшение.
Это было мое понимание: раньше имело значение, больше не
Не с точки зрения производительности - действует как средство ограничения доступа. Но это уже другая тема. ;)
о, конечно, лоты веских причин для использования представлений, а не ни одного для использования сырых запросов: P
Я ожидал, что два запроса будут выполняться одинаково. Представление - это не что иное, как сохраненное определение запроса, здесь нет кеширования или хранения данных для представления. Оптимизатор эффективно превратит ваш первый запрос во второй, когда вы его запустите.
Если представление представляет собой небольшой набор полей, и эти поля затем покрываются индексом, достаточно ли умен SQL Server, чтобы использовать этот покрывающий индекс при выполнении второй формы запроса?
Практического отличия нет, и если вы прочитаете BOL, вы обнаружите, что когда-либо ваш простой старый SQL SELECT * FROM X действительно использует кеширование планов и т. д.
По крайней мере, в SQL Server планы запросов хранятся в кэше планов как для представлений, так и для обычных SQL-запросов на основе параметров запроса / представления. Для обоих они удаляются из кеша, если они не использовались в течение достаточно длительного периода времени, и место требуется для какого-либо другого вновь отправленного запроса. После этого, если будет выдан тот же запрос, он будет перекомпилирован, и план будет помещен обратно в кэш. Так что нет никакой разницы, учитывая, что вы повторно используете один и тот же SQL-запрос и одно и то же представление с той же частотой.
Очевидно, что в целом представление по самой своей природе (кто-то думал, что оно должно использоваться достаточно часто, чтобы превратить его в представление) обычно более вероятно будет «повторно использовано», чем любой произвольный оператор SQL.
Сохранение плана выполнения должно дать некоторую тривиальную выгоду, но она будет незначительной.
Цель представления - использовать запрос снова и снова. С этой целью SQL Server, Oracle и т. д. Обычно предоставляют «кэшированную» или «скомпилированную» версию вашего представления, тем самым улучшая его производительность. В общем, это должно работать лучше, чем «простой» запрос, хотя, если запрос действительно очень простой, преимущества могут быть незначительными.
Теперь, если вы выполняете сложный запрос, создайте представление.
Определенно представление лучше, чем вложенный запрос для SQL Server. Не зная точно, почему это лучше (пока я не прочитал сообщение Марка Бриттингема), я провел несколько тестов и испытал почти шокирующие улучшения производительности при использовании представления по сравнению с вложенным запросом. После выполнения каждой версии запроса несколько сотен раз подряд версия запроса выполнялась вдвое быстрее. Я бы сказал, этого для меня достаточно.
Спасибо, Джордан ... рад слышать, что вся эта теория работает в мире настоящий.
У меня есть опыт работы с вложенным представлением (представление в представлении), и у меня была очень плохая производительность. Когда все представления были переписаны на подвыборки, производительность была во много раз выше, так что, возможно, есть место для серьезного тестирования.
Вообще-то нет. Представления в основном используются для удобства и безопасности и (сами по себе) не приносят никакого выигрыша в скорости.
Тем не менее, в SQL Server 2000 и более поздних версиях есть функция под названием Индексированные просмотры, которая значительно повышает производительность может, с некоторыми оговорками:
- Не каждое представление можно превратить в индексированное представление; они должны следовать конкретный набор руководящих принципов, что (среди других ограничений) означает, что вы не можете включать общие элементы запроса, такие как
COUNT,MIN,MAXилиTOP. - Индексированные представления используют физическое пространство в базе данных, как индексы в таблице.
В этой статье описываются дополнительные преимущества и ограничения индексированных представлений:
You Can…
- The view definition can reference one or more tables in the same database.
- Once the unique clustered index is created, additional nonclustered indexes can be created against the view.
- You can update the data in the underlying tables – including inserts, updates, deletes, and even truncates.
You Can’t…
- The view definition can’t reference other views, or tables in other databases.
- It can’t contain COUNT, MIN, MAX, TOP, outer joins, or a few other keywords or elements.
- You can’t modify the underlying tables and columns. The view is created with the WITH SCHEMABINDING option.
- You can’t always predict what the query optimizer will do. If you’re using Enterprise Edition, it will automatically consider the unique clustered index as an option for a query – but if it finds a “better” index, that will be used. You could force the optimizer to use the index through the WITH NOEXPAND hint – but be cautious when using any hint.
совершенно не согласен ... чтение из представления позволяет переписать SQL .. и, как правило, читать из представления БЫСТРЕЕ (чем из дампа представления).
@AaronKempf, я бы хотел увидеть ссылку на это, это не было моим опытом. Когда я ищу «просмотреть перезаписанный SQL», все полученные мной результаты относятся к Oracle, а не к серверу SQL, например docs.oracle.com/cd/E14072_01/server.112/e10810/qrbasic.htm
Вчера я просто проводил сравнительный анализ, я был ошеломлен ... в основном, если я возьму дамп из представления (в таблицу), любой запрос, который я выполняю, будет МЕДЛЕННЫМ .. потому что большинство запросов проходят через представление, как масло, и переписываются оптимизатором запросов .. По крайней мере, я так предполагаю. Я постараюсь в ближайшее время написать об этом в блоге, тестирование было довольно увлекательным занятием .. В основном просмотры очень помогают производительности.
@AaronKempf Не уверен, что это даже тот же сценарий, что и исходный вопрос (который касается запроса и помещения этого идентичного запроса в представление). В любом случае, я не могу понять, как материализация представления в таблице сделает его МЕДЛЕННЫМ (это именно то, что делает индексированное представление), если только ваша новая таблица не имеет хороших индексов.
например .. У меня есть КОНСТАНТА в представлении, и я могу продемонстрировать, что в ~ 99 раз быстрее попасть в эту КОНСТАНТУ вместо данных, стоящих за представлением.
11 лет спустя я все еще не нашел много хороших кандидатов для индексированных представлений, учитывая "несколько [небольших] предостережений" ..: |
По моему мнению, использование представления немного быстрее, чем обычный запрос. Мой хранимая процедура занимал около 25 минут (работа с другими более крупными наборами записей и несколькими объединениями), и после использования представления (некластеризованного) производительность была немного выше, но совсем не значима. Мне пришлось использовать некоторые другие методы / методы оптимизации запросов, чтобы кардинально изменить ситуацию.
Очень важно, как мы пишем / проектируем запрос.
Я обнаружил, что использование CTE для ограничения данных, возвращаемых из таблицы, а затем выполнения всей работы / объединений и т. д. С CTE, значительно улучшило производительность во многих случаях.
Все зависит от ситуации. Индексированные представления MS SQL работают быстрее, чем обычное представление или запрос, но индексированные представления не могут использоваться в зеркальной среде базы данных (MS SQL).
Представление в любом виде цикла вызовет серьезное замедление, потому что представление повторно заполняется каждый раз, когда оно вызывается в цикле. То же, что и запрос. В этой ситуации временная таблица, использующая # или @ для хранения ваших данных в цикле, работает быстрее, чем представление или запрос.
Так что все зависит от ситуации.
Выбор из представления или из таблицы не имеет особого смысла.
Конечно, если в представлении нет ненужных объединений, полей и т. д. Вы можете проверить план выполнения ваших запросов, объединений и индексов, используемых для повышения производительности представления.
Вы даже можете создать индекс для представлений для более быстрого поиска. 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 в один вложенный запрос и выполнить его за пару секунд.
Мы даже обнаружили, что можем даже записать каждое представление во временную таблицу и запросить ее вместо представления, и это все еще было намного быстрее, чем просто использование вложенных представлений.
Еще более странным было то, что производительность была хорошей, пока мы не достигли некоторого предела исходных строк, втягиваемых в базу данных, производительность просто упала со скалы в течение пары дней - все, что потребовалось, - это еще несколько исходных строк.
Таким образом, использование запросов, которые извлекают из представлений, которые извлекают из представлений, намного медленнее, чем вложенный запрос, что для меня не имеет смысла.
Я наткнулся на эту ветку и просто хотел поделиться этим сообщением от Брента Озара, как что-то, что нужно учитывать при использовании групп доступности.
Я не уверен насчет одного представления, но вложенные представления - это настоящий ад.