Индексированное представление для повышения производительности нескольких соединений на SQL Server

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

Чтобы повысить производительность, я создал индексированное представление и вижу значительное улучшение производительности запроса в представлении с фильтром даты. Однако меня беспокоит хранение индекса. Из того, что я прочитал, уникальный кластерный индекс хранится на SQL Server. Означает ли это, что он хранит отдельно все данные, полученные как часть объединений в представлении? Если да, то если бы я включил в представление все столбцы из таблиц, которые являются частью объединений, будет ли потребляемое дисковое пространство на сервере примерно вдвое больше дискового пространства без индексированного представления? И каждый раз, когда я ввожу данные в базовые таблицы, данные дублируются для индексированного представления?


sql sql-server indexing indexed-view
person Manish Mulani    schedule 19.02.2013    source источник

Ответы (3)


arrow_upward
4
arrow_downward

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

person Rob Boek    schedule 19.02.2013

arrow_upward
6
arrow_downward

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

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

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

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

person Sebastian Meine    schedule 19.02.2013

arrow_upward
4
arrow_downward

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

person chrisb    schedule 19.02.2013