Является
select * from myView
быстрее самого запроса для создания представления (для того, чтобы иметь тот же набор результатов):
select * from ([query to create same resultSet as myView])
?
Мне не совсем понятно, если представление использует какое-то кэширование, что делает его быстрее по сравнению с простым запросом.
Да, представления могут иметь назначенный кластеризованный индекс, и, когда они это сделают, они будут хранить временные результаты, которые могут ускорить возникающие запросы.
Обновление: по меньшей мере три человека проголосовали за меня. При всем моем уважении, я думаю, что они просто ошибаются; В документации Microsoft очень ясно, что Views может повысить производительность.
Во-первых, простые представления расширяются на месте и поэтому не вносят непосредственного вклада в улучшение производительности - это так. Однако индексированные представления могут значительно повысить производительность.
Перейдем непосредственно к документации:
После создания на представлении уникального кластерного индекса набор результатов будет реализован немедленно и сохранен в физическом хранилище в базе данных, сохраняя накладные расходы на выполнение этой дорогостоящей операции во время выполнения.
Во-вторых, эти индексированные представления могут работать даже тогда, когда они напрямую не ссылаются на другой запрос, поскольку оптимизатор будет использовать их вместо ссылки на таблицу, когда это необходимо.
Опять же, документация:
Индексированное представление может использоваться в выполнении запроса двумя способами. Запрос может ссылаться на индексированный вид напрямую, или, что более важно, оптимизатор запросов может выбрать представление, если он определяет, что представление может быть заменено на какой-либо или весь запрос в самом низком ценовом плане. Во втором случае вместо таблиц и их обычных индексов используется индексированное представление. На просмотр не нужно ссылаться в запросе оптимизатора запросов для его использования во время выполнения запроса. Это позволяет существующим приложениям извлекать выгоду из вновь созданных индексированных представлений без изменения этих приложений.
Эта документация, а также диаграммы, демонстрирующие улучшения производительности, можно найти здесь.
Обновление 2: ответ подвергся критике на том основании, что это "индекс", который обеспечивает преимущество производительности, а не "вид". Однако это легко опровергнуть.
Скажем, что мы являемся софтверной компанией в маленькой стране; Я приведу Литву в качестве примера. Мы продаем программное обеспечение по всему миру и сохраняем наши записи в базе данных SQL Server. Мы очень успешны, и поэтому через несколько лет у нас есть 1 000 000 записей. Однако нам часто приходится сообщать о продажах для целей налогообложения, и мы обнаруживаем, что мы продали только 100 копий нашего программного обеспечения в нашей стране. Создавая индексный вид только литовских записей, мы получаем, чтобы вести записи, которые нам нужны, в индексированном кеше, как описано в документации MS. Когда мы запускаем наши отчеты для продаж в Литве в 2008 году, наш запрос будет искать по индексу с глубиной всего 7 (Log2 (100) с некоторыми неиспользуемыми листами). Если бы мы сделали то же самое без VIEW и просто полагаясь на индекс в таблицу, нам пришлось бы пересекать дерево индексов с глубиной поиска 21!
Очевидно, что сам вид предоставит нам преимущество в производительности (3x) за простое использование индекса. Я попытался использовать реальный пример, но вы заметите, что простой список продаж в Литве даст нам еще большее преимущество.
Обратите внимание, что я просто использую прямое дерево b-tree для моего примера. Хотя я вполне уверен, что SQL Server использует какой-то вариант b-дерева, я не знаю деталей. Тем не менее точка имеет место.
Обновление 3: Возникает вопрос, использует ли индексированный вид только индекс, помещенный в базовую таблицу. То есть, перефразируя: "индексированное представление является просто эквивалентом стандартного индекса и не предлагает ничего нового или уникального для представления". Если бы это было так, конечно, то приведенный выше анализ был бы неправильным! Позвольте мне предоставить цитату из документации Microsoft, которая показывает, почему я считаю, что эта критика неверна или верна:
Использование индексов для повышения эффективности запросов не является новой концепцией; однако индексированные представления обеспечивают дополнительные преимущества, которые не могут быть достигнуты с использованием стандартных индексов.
Вместе с приведенной выше цитатой о сохранении данных в физическом хранилище и другой информации в документации о том, как индексы создаются в представлениях, я думаю, можно с уверенностью сказать, что индексированный вид не просто кешированный SQL Select, который использует индекс, определенный в главной таблице. Таким образом, я продолжаю поддерживать этот ответ.
Вообще говоря, нет. Представления в основном используются для удобства и безопасности, а не для улучшения скорости.
Тем не менее, SQL Server 2000 и выше имеют специальную функцию под названием Indexed Views, которая может значительно повысить производительность, но вам нужно создать индексированные представления, следуя очень определенный набор рекомендаций.
Существует важная ссылка в Books Online относительно разрешения просмотра.
Вот статья, описывающая преимущества и создание индексированных представлений:
В течение многих лет Microsoft® SQL Server ™ поддерживает возможность создания виртуальные таблицы, известные как виды. Исторически эти взгляды служили этим основные цели:
Предоставить механизм безопасности, который ограничивает пользователей определенным подмножеством данных в одной или нескольких базовых таблицах.
Предоставить механизм, позволяющий разработчиков, чтобы настроить, как пользователи могут логически просматривать данные, хранящиеся в базе таблицы.
В SQL Server 2000 функциональность представлений SQL Server была расширен для обеспечения производительности системы выгоды. Можно создать уникальный кластерный индекс на вид, так как а также некластеризованные индексы, чтобы повысить производительность доступа к данным на наиболее сложные запросы. В SQL Server 2000 и 2005 гг., уникальный кластеризованный индекс как индексированный вид.
В SQL Server, по крайней мере, планы запросов хранятся в кеше плана для обоих представлений и обычных SQL-запросов на основе параметров запроса/представления. Для обоих они удаляются из кеша, когда они не используются в течение достаточно длительного периода времени, и пространство необходимо для какого-либо другого вновь представленного запроса. После этого, если выдается тот же запрос, он перекомпилируется и план возвращается в кеш. Таким образом, нет, нет никакой разницы, учитывая, что вы повторно используете один и тот же запрос SQL и тот же вид с той же частотой.
Очевидно, что в общем случае представление, по своей природе (что кто-то думал, что его нужно использовать достаточно часто, чтобы превратить его в представление), скорее всего, будет "повторно использоваться", чем любой произвольный оператор SQL.
РЕДАКТИРОВАТЬ: я был неправ, и вы должны увидеть Отметить ответ выше.
Я не могу говорить по опыту SQL Server, но для большинства баз данных ответ будет отрицательным. Единственное потенциальное преимущество, которое вы получаете от эффективности использования, состоит в том, что оно потенциально может создать некоторые пути доступа на основе запроса. Но основной причиной использования представления является упрощение запроса или стандартизация способа доступа к некоторым данным в таблице. Вообще говоря, вы не получите выгоды от производительности. Хотя я могу ошибаться.
Я бы придумал умеренно более сложный пример и время, которое он сам видел.
Это может быть быстрее, если вы создадите материализованное представление (с привязкой схемы). Не материализованные представления выполняются так же, как обычный запрос.
Я понимаю, что некоторое время назад представление будет быстрее, потому что SQL Server может сохранить план выполнения, а затем просто использовать его вместо того, чтобы пытаться понять его на лету. Я думаю, что производительность в настоящее время, вероятно, не так велика, как когда-то, но я должен был догадаться, что было бы небольшое улучшение для использования представления.
Я бы ожидал, что два запроса будут выполняться одинаково. Представление - это не что иное, как определение хранимого запроса, не существует кэширования или хранения данных для представления. Оптимизатор эффективно превратит ваш первый запрос в ваш второй запрос при его запуске.
Определенно представление лучше, чем вложенный запрос для SQL Server. Не зная точно, почему это лучше (пока я не прочитал пост Марка Бриттингема), я провел несколько тестов и испытал почти шокирующие улучшения производительности при использовании представления против вложенного запроса. После запуска каждой версии запроса несколько сотен раз подряд, версия запроса запроса завершена за половину времени. Я бы сказал, что для меня достаточно доказательств.
Нет никакого практического разного, и если вы прочитаете BOL, вы обнаружите, что когда-либо ваш простой старый SQL SELECT * FROM X использует преимущества кэширования планов и т.д.
Должен быть некоторый тривиальный выигрыш в сохранении плана выполнения, но он будет незначительным.
Цель представления - использовать запрос снова и снова. С этой целью SQL Server, Oracle и т.д. Обычно предоставляют "кэшированную" или "скомпилированную" версию вашего представления, тем самым улучшая ее производительность. В общем, это должно работать лучше, чем "простой" запрос, хотя если запрос действительно очень простой, преимущества могут быть незначительными.
Теперь, если вы выполняете сложный запрос, создайте представление.
В моем поиске использование представления немного быстрее обычного запроса. Моя хранимая процедура занимала около 25 минут (работа с разными большими наборами записей и несколькими объединениями) и после использования представления (некластеризованного) производительность была немного быстрее, но не значительна. Мне пришлось использовать некоторые другие методы/методы оптимизации запросов, чтобы сделать его драматическим.
Все зависит от ситуации. Индексированные представления MS SQL быстрее обычного просмотра или запроса, но индексированные представления не могут использоваться в зеркалированной базе данных (MS SQL).
Вид в любом виде цикла вызовет серьезное замедление, потому что представление повторно заполняется каждый раз, когда оно вызывается в цикле. То же, что и запрос. В этой ситуации временная таблица, использующая # или @для хранения ваших данных, проходит быстрее, чем представление или запрос.
Итак, все зависит от ситуации.
Выбор из представления или из таблицы не будет иметь особого смысла.
Конечно, если View не имеет ненужных объединений, полей и т.д. Вы можете проверить план выполнения ваших запросов, объединений и индексов, используемых для улучшения производительности View.
Вы даже можете создать индекс для просмотров для более быстрого поиска. 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+