Производительность представления по сравнению с запросом (с операторами объединения) - PullRequest
0 голосов
/ 30 августа 2010

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

select
Name, Code, Date From TableA
union
select
Surname, TheCode, TheDate From TableB
union
[...] -- this stands for some more select statements
union
select
NickName, MyCode, getdate() from tableC

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

Этот запрос может вернуть 100 000 записей, даже если обычно это будет 400-500 из-за условий WHERE.

Я рассматриваю возможность использования представленияупростить запросы, но имеет ли это смысл?Запрашивает ли представление быстрее, потому что представление предварительно вычислено (я не уверен в этом), или представление выполняется так, как оно запрашивается?Я имею в виду: если 10 пользователей запрашивают одни и те же данные, выполняя 10 запросов к таблицам с объединениями или выполняя 10 запросов к представлению, это одно и то же или лучше иметь представление?(Я имею в виду, что если представление выполняется только один раз, лучше, если нет, то оно точно такое же).

Более того, я не могу использовать индексированное представление, поскольку я использую UNION STATEMENTS.

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

Ответы [ 3 ]

1 голос
/ 30 августа 2010

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

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

1 голос
/ 30 августа 2010

Вы не упоминаете, какая у вас версия или редакция MSSQL, но, возможно, вы ищете «многораздельные представления» или даже «многораздельные таблицы» (подробности см. В Books Online)Получат ли они какую-либо пользу для вас или нет, зависит от того, сколько у вас данных, и тестирование будет лучшим способом выяснить это.имя представления заменяется определением представления при запросе, поэтому MSSQL в любом случае никогда не «видит» представление.Исключением являются индексированные представления, где планировщик запросов может получать данные из представления, а не из таблицы.Но индексированные представления также имеют недостатки.В Books Online много полезной информации: ищите «Разрешение просмотра», «Разрешение индексов в представлениях», «Создание индексированных представлений» и т. Д.

1 голос
/ 30 августа 2010

Используйте UNION ALL, это не делает DISTINCT (UNION делает это)

Это говорит то же самое.

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