Вид быстрее, чем простой запрос?

Question

Вид быстрее, чем простой запрос?

Это

select *  from myView

быстрее, чем сам запрос для создания представления (для того, чтобы иметь тот же результат):

select * from ([query to create same resultSet as myView])

?

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

539 14

performance sql-server sql

14 ответов:

Comments

Ничего не найдено.

Mark Brittingham · Accepted Answer · 2009-11-15 14:47:16

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

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

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

позвольте мне перейти непосредственно к документации:

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

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

опять же, в документации:

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

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

обновление 2: ответ был подвергнут критике на том основании, что именно" индекс "обеспечивает преимущество в производительности, а не "представление"."Однако, это легко опровергается.

скажем, что мы являемся софтверной компанией в небольшой стране; я буду использовать Литву в качестве примера. Мы продаем программное обеспечение по всему миру и храним наши записи в базе данных SQL Server. Мы очень успешны, и поэтому через несколько лет у нас будет 1 000 000+ записей. Однако нам часто приходится сообщать о продажах для целей налогообложения, и мы обнаруживаем, что мы продали только 100 копий нашего программного обеспечения в нашей родной стране. Путем создания индексированного представления только рекордов Литвы, то вам, чтобы сохранить записи нужно в индексированном кэша, как описано в MS документации. Когда мы запускаем наши отчеты по литовским продажам в 2008 году, наш запрос будет искать по индексу с глубиной всего 7 (Log2(100) с некоторыми неиспользуемыми листьями). Если бы мы сделали то же самое без вида и просто полагаясь на индекс в таблице, мы должны были бы пересечь дерево индексов с глубиной поиска 21!

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

обратите внимание, что я просто использую прямое b-дерево для моего примера. Хотя я уверен, что SQL Server использует некоторые вариант Б-дерева, я не знаю подробностей. Тем не менее, точка зрения остается.

обновление 3: возник вопрос о том, использует ли индексированное представление только индекс, помещенный в базовую таблицу. То есть, перефразируя: "индексированное представление-это просто эквивалент стандартного индекса, и оно не предлагает ничего нового или уникального для представления."Если бы это было правдой, конечно, то приведенный выше анализ был бы неверным! Позвольте мне привести цитату из документации Microsoft, что продемонстрируйте, почему я думаю, что эта критика не является действительной или истинной:

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

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

BradC · Accepted Answer · 2009-11-16 00:20:50

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

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

есть важная ссылка в книгах онлайн в отношении посмотреть разрешение.

вот статья, которая описывает льготы и создание индексированных представлений:

в течение многих лет Microsoft® SQL Server™ поддерживает возможность создания виртуальные таблицы, известные как представления. Исторически эти взгляды служили этим основные цели:

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

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

с SQL Server 2000, функциональность представлений SQL Server была расширен для обеспечения производительности системы выгоды. Можно создать уникальный кластеризованный индекс в представлении, как а также некластеризованные индексы, чтобы улучшить производительность доступа к данным на самые сложные запросы. В SQL Сервер 2000 и 2005 годы, мнение, которое имеет уникальный кластеризованный индекс называется как индексированное представление.

Charles Bretana · Accepted Answer · 2009-01-13 16:21:56

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

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

Ryan Guill · Accepted Answer · 2017-05-23 14:47:32

EDIT: я был неправ, и вы должны увидеть знаки ответ выше.

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

Я бы с умеренно более сложный пример и время себя, чтобы увидеть.

Otávio Décio · Accepted Answer · 2012-08-27 21:17:59

Это может быть быстрее, если создать материализованное представление (С привязкой схемы). Нематериализованные представления выполняются так же, как и обычный запрос.

E.J. Brennan · Accepted Answer · 2012-08-27 21:18:47

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

Tony Andrews · Accepted Answer · 2009-01-13 16:14:41

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

score 2 · Accepted Answer · 2009-01-13 18:03:51

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

keithwarren7 · Accepted Answer · 2009-01-13 16:15:14

нет никакой практической разницы, и если Вы читаете BOL, вы обнаружите, что когда-либо ваш простой старый SQL SELECT * FROM X использует кэширование планов и т. д.

JosephStyons · Accepted Answer · 2009-01-13 16:31:45

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

score 0 · Accepted Answer · 2009-01-13 16:35:27

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

теперь, если вы делаете сложный запрос, создать представление.

kta · Accepted Answer · 2012-08-27 21:22:02

на мой взгляд, использование представления немного быстрее, чем обычный запрос. Мой хранимая процедура заняло около 25 минут (работа с разными большими наборами записей и несколькими соединениями), и после использования представления (некластеризованного) производительность была немного быстрее, но не значительна вообще. Мне пришлось использовать некоторые другие методы оптимизации запросов/метод, чтобы сделать это резкое изменение.

Dasboot · Accepted Answer · 2013-03-15 16:24:17

все зависит от ситуации. Индексированные представления MS SQL работают быстрее обычного представления или запроса, но индексированные представления нельзя использовать в зеркальной среде базы данных (MS SQL).

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

Так что все зависит от положение.

Mohamad Shahrestani · Accepted Answer · 2017-04-18 09:58:14

выбор из представления или из таблицы не будет иметь слишком большого смысла.

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

вы даже можете создать индекс на представлениях для более быстрого поиска требований. 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+