2013-09-30 2 views
0

У меня есть случай с несколькими объединениями для нескольких таблиц с различными предложениями.Просмотр, индексированный просмотр и запрос соединения. Что лучше для разных объединений?

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

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

нескольких объединений принесет правильные данные через ИНЕКЕ запрос без необходимости сначала выводить и фильтровать его позже (простые представления), так и необходимость поддерживать индексы для индексированных представлений на несколько часто меняющихся данных, но приведет к более сложным запросам.

Эти объединения включают в себя до 20 таблиц (некоторые внешние (от 2 до 4) объединений, которые должны быть записаны в любом случае, поскольку индексированные представления не поддерживают их), а строки результатов - несколько тысяч (от 2 до 4 миллион строк в каждом представлении).

Это скорее вопрос дизайна, но какой будет самый эффективный (с точки зрения производительности и хранения) в этом случае?

P.S. Запросы довольно утомительны, чтобы писать каждый раз в области разработки интерфейса, поэтому я ищу еще одно решение.

+5

«* Простой вид всегда будет запускать оператор select (это то, что сохраняется в базе данных в любом случае) *« Нет, это не то, как работают Views. Само по себе представление ничего не делает и не сохраняет никаких данных. Просмотр - это просто псевдоним SQL-запроса. Его можно использовать только в других запросах, которые ссылаются на него. Когда это произойдет, компилятор запросов затем оптимизирует его вместе со всеми остальными частями запроса, включая любые предложения WHERE или другие ограничения. Так часто, как нет, это приведет к тому, что внешние явные предложения WHERE будут применены * до того, как * результаты представления будут добавлены ко всему остальному. – RBarryYoung

+0

Спасибо, что я этого не знал. Я думал, что это работает как псевдоним для вложенного запроса. Таким образом, с точки зрения эффективности использования простого представления нет проблем. Но лучше ли индексированное представление? –

ответ

1

Несколько советов по оптимизации производительности запросов.

Номер 1: Используйте фильтры, где можно, оптимизатор будет использовать эти фильтры для ограничения возвращаемых данных (наличие таблицы из 100 000 000 строк, фильтры фактически ускоряют процесс просмотра).

Номер 2: Неявные преобразования: неявное преобразование - это то место, где вы не видите перехода от одного типа данных к другому, но за кулисами они пережевывают много времени. 6 000 000 строк таблицы с удаленного сервера. 2 минуты времени запроса с неявным преобразованием, через 5 секунд после удаления неявного преобразования (BTW datetime <> smalldatetime).

Номер 3: используйте план выполнения, который позволит вам узнать, где находятся ваши самые большие интенсивные операции с ЦП (так я обнаружил неявное преобразование Datetime -> Smalldatetime).

Смежные вопросы