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

Question

У меня есть следующая таблица

EVENT_LOG:

EVENT_ID: pk, int, not null 
TYPEID: fk, int, not null 
CATEGORYID: fk, int, null 
SOURCE: varchar(255), null 
DESCRIPTION: varchar(4000), null 
CREATED: datetime, null 

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

Мы задавались вопросом, является ли вариант indexed view (материализованный вид AKA), в котором индексированный вид будет содержать все столбцы из таблицы EVENT_LOG, но с соответствующими индексами, созданными на представлении. Поможет ли нам получить отчетность, не влияя на запись в таблицу EVENT_LOG?

Answer 1

Индексированного вид будет вызывать те же проблемы, как индекс на колонке, поскольку индексированные представления требуют with schemabinding, что привязать его к столу сразу, запрещая вас от изменения/изменения схемы этой таблицы в любом случае, форма, или формы. Это включает изменение размера столбца (например, от varchar(50) до varchar(255)), изменение типа данных столбца (например, от double до decimal(18,5)) и т. Д. Я видел, что из-за этого они вызвали много неожиданных головных болей.

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

Answer 2

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

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

Answer 3

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

Answer 4

У меня возникла аналогичная проблема. Решил добавить многоколоночный индекс против рекомендаций от администратора базы данных. На моей машине разработки и сервере (с разрешениями DBA) производительность для записи увеличилась и отчетность была значительно быстрее (17x), чем создание индексов по отдельным столбцам. Почему, я не знаю, так как я не являюсь администратором баз данных, но я знаю основы, и иногда это помогает вам видеть сквозь лес/деревья. Поэтому я согласен с Эриком Пертроэлье, вы должны добавить индексы и измерить производительность записи и даже измерить производительность чтения.

Answer 5

«Источник & описание столбцов нужно искать подстроки.»

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

Я думаю, что лучше создать полнотекстовый указатель на «Источник» и «Описание», если вам нужно искать подстроки в них.

Таким образом, мое предложение состояло в создании индекса Full Text Index на столбцах varchar() и внесении изменений в качестве руководства и запуска его каждый час или около того, когда DML не будет ..., что уменьшит нагрузки на Заявления INSERT