Несколько индексов против принудительного сканирования таблиц - PullRequest
Новая
       11

Несколько индексов против принудительного сканирования таблиц

2 голосов
/ 13 ноября 2010

Я занимаюсь оптимизацией индексов в БД SQL Server 2008, над которой я работаю. Прямо сейчас я на «центральном» столе.

Эта таблица объединена в 7 столбцов. Он также имеет первичный ключ (конечно), а также метку даты, которую я проиндексировал в порядке DESC. Я считаю, что из-за характера объединений требуется 6 индексов (некоторые объединения относятся к таблицам со сверхнизким количеством элементов или не будут запрошены).

Однако, эта таблица сильно записана. Производительность будет низкой с 6 индексами (и 1 - это индекс с 2 столбцами). Запросы можно запускать для большинства соединенных таблиц, поэтому я не вижу, как можно отбросить какие-либо индексы.

Кто-нибудь знает лучшую практику определения баланса между индексами?

Обновление:

Вот интересующие вас столбцы в таблице: 

MentionID       int             primary key
ParentID         int             indexed
ProfileID       int             indexed
SourceCategoryID tinyint         indexed with next column
SourceID         int
RoleplayerID     int             indexed
DateStamp       smalldatetime   indexed DESC
Subject       nvarchar(1000)
KeyMessage     nvarchar(1000)
SentimentID   tinyint         unindexed: low cardinality
ScopeID       tinyint         unindexed: low cardinality

1 Ответ

1 голос
/ 13 ноября 2010

Только одна «лучшая практика»: попытаться измерить, измерить, измерить и еще раз измерить.

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

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

С другой стороны: у SQL Server также есть DMV, который сообщает вам, какие индексы он считает полезными и поможет ускорить ваши запросы - время от времени проверяйте этот DMV, чтобы узнать, что оптимизатор запросов SQL Server хотел бы добавили; если это соответствует индексам, которые вы собирались создать, вы, вероятно, на правильном пути!

...