Вопрос по индексированному представлению SQL Server

Question

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

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

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

Существует ли какое-либо руководство по передовому опыту в отношении того, когда использовать представления индекса, а когда - нет? Будет ли представление перестраиваться после каждого перезапуска сервера или хранится где-то на диске?

Answer 1

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

Большое количество обновлений, скорее всего, убьет выгоду. Если он в основном читает, он будет работать нормально.

Реальные преимущества индексированных представлений - это когда у вас есть агрегаты, которые слишком дороги для вычисления в реальном времени.

См. Повышение производительности с помощью индексированных представлений SQL Server 2008 :

Индексированные представления могут увеличить запрос производительность следующими способами:

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

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

Приложения, которые получают выгоду от реализация индексированных представлений включают в себя:

• Рабочие нагрузки поддержки принятия решений.
• витрины данных.
• Хранилища данных.
• Интернет-магазины и источники аналитической обработки (OLAP).
• Рабочие нагрузки интеллектуального анализа данных.

От типа запроса и точки шаблона зрения, полезных приложений можно охарактеризовать как содержащий:

• Объединения и объединения больших таблиц.
• Повторные шаблоны запросов.
• Повторные агрегации для одинаковых или перекрывающихся наборов столбцов.
• Повторные объединения тех же таблиц на одних и тех же ключах.
• Комбинации вышеперечисленного.

Answer 2

Индексированное представление (также называемое материализованным представлением) поддерживается SQL Server после каждого изменения базовой таблицы. Излишне говорить, что у вас не должно быть индексированного представления для таблицы с трафиком.

Для вашей проблемы лучшим решением было бы запустить запрос и сохранить его в собственной таблице, например:

select * into CachedReport from YourView

Это даст вам производительность индексированного представления, а вы сможете решить, когда его обновить. Например, вы можете обновить его, выполняя запрос select into из запланированного задания каждую ночь.

Answer 3

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

Сначала Тимоти предложил проверить индексы ваших базовых таблиц, а затем статистику. Ваш Оптимизатор запросов может быть только на пути к цели из-за отсутствия / устаревшей статистики.

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

Answer 4

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

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