Оптимизация просмотров - PullRequest
2 голосов
/ 27 декабря 2011

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

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

Можете ли вы дать мне несколько советов, как улучшить производительность большинства внешних видов?

Или как улучшить производительность в целом.

Спасибо.

РЕДАКТИРОВАТЬ : Я также слышал, что это не очень хорошая стратегия использовать вид изнутри, верно?

Ответы [ 3 ]

3 голосов
/ 27 декабря 2011
  • Представления являются макросами
  • Они раскрываются во время выполнения
  • Они не инкапсулируют и не выполняют предварительный расчет запросов **
  • Они не являются оптимизацией
  • DRY не всегда применяется к базам данных (в случае представлений, представленных разработчиками клиента)

По сути, удалите представления.Обычно они вам не нужны.

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

** indexedили материализованные представления, но у них есть ограничения на использование

2 голосов
/ 27 декабря 2011

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

КРОМЕ

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

А как насчет стратегии взглядов внутри взглядов - вкус имеет значение, я думаю, что это не красиво, но я не могу назвать это стратегией 8 -)

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

0 голосов
/ 27 декабря 2011

Я думаю, что здесь все очень хорошо объясняется Посмотреть вопрос о производительности

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

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

...