Является ли представление быстрее, чем простой запрос?

Question

select *  from myView

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

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

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

Answer 1

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

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

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

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

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

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

Опять документация:

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

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

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

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

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

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

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

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

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

Answer 2

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

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

В Books Online есть важная ссылка на разрешение просмотра .

Вот статья, описывающая преимущества и создание индексированных представлений :

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

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

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

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

Answer 3

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

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

Answer 4

РЕДАКТИРОВАТЬ: Я был неправ, и вы должны увидеть Отмечает ответ выше.

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

Я бы придумал немного более сложный пример и сам его посмотрел.

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

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

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

Answer 10

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

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

Так что все зависит от ситуации.