Индексированное представление против индексов в таблице

Question

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

EVENT_LOG * * 1004

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

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

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

Answer 1

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

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

Answer 2

"В столбцах источника и описания необходимо искать подстроки."

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

Полагаю, лучше создать полнотекстовый указатель для 'Source' и 'Description', если вам нужно искать в них подстроки.

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

Answer 3

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

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

Answer 4

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

Answer 5

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