Индексы SQL Server не помогают

У меня есть таблица (SQL 2000) с более чем 10000000 записей. Записи добавляются в размере примерно 80 000-100 000 в неделю. Раз в неделю из данных генерируется несколько отчетов. Отчеты, как правило, работают довольно медленно, потому что индексов мало (предположительно, для ускорения INSERT). Один новый отчет может действительно выиграть от дополнительного индекса по конкретному столбцу "char (3)".

Я добавил индекс с помощью Enterprise Manager (Управление индексами -> Новый -> Выбрать столбец, ОК) и даже перестроил индексы в таблице, но запрос SELECT вообще не ускорился. Любые идеи?

Обновление :

Определение таблицы:

ID, int, PK
Source, char(3)  <--- column I want indexed
...
About 20 different varchar fields
...
CreatedDate, datetime
Status, tinyint
ExternalID, uniqueidentifier

Мой тестовый запрос просто:

select top 10000 [field list] where Source = 'abc'
11.12.2008 21:07:43
Определение таблицы и строка запроса необходимы для ответа на этот вопрос. Ошибка может быть полностью где-то еще.
Tomalak 11.12.2008 21:10:19
Также опубликуйте результаты EXPLAIN
Eran Galperin 11.12.2008 21:13:05
Сколько разных значений в Source по сравнению с количеством строк таблицы? Индекс КЛАСТЕРНЫЙ или нет?
Tomalak 11.12.2008 21:22:02
Другим индексом является индекс CLUSTERED. В настоящее время существует около 400 вариантов источника, хотя некоторые из них используются гораздо чаще, чем другие.
Scott Isaacs 11.12.2008 21:23:48
По отношению к миллионам строк таблицы 400 различных значений не так много с точки зрения селективности. Может быть, индекс даже не используется из-за этого. Попробуйте сделать Source индекс CLUSTERED.
Tomalak 11.12.2008 21:26:39
4 ОТВЕТА
РЕШЕНИЕ

Вам нужно взглянуть на план запроса и посмотреть, использует ли он этот новый индекс - если нет, есть пара вещей. Во-первых, у него может быть план кэшированных запросов, который он использует и который не был аннулирован с момента создания нового индекса. Если это не так, вы также можете попробовать подсказки индекса [With (Index (yourindexname))].

1000000 строк не неслыханно, это должно быть прочитано довольно быстро.

5
11.12.2008 21:55:42
«это должно быть прочитано довольно быстро», это смелое утверждение, учитывая тот факт, что вы ничего не знаете о конфигурации оборудования, версии SQL-сервера, объеме ОЗУ, другой загрузке, настройке диска, ...)
Tomalak 11.12.2008 22:05:38
Это был «намек», который мне был нужен (каламбур). Запрос теперь выполняется в течение <2 секунд. Спасибо.
Scott Isaacs 11.12.2008 22:29:22
Томалак - хорошая мысль. Я просто делал общее предположение, но, похоже, он был успешным.
keithwarren7 12.12.2008 00:12:10
Поэтому я думаю, что это показывает, что индекс не использовался автоматически из-за его низкой избирательности, и вместо этого произошло полное сканирование таблицы.
Tomalak 12.12.2008 11:14:25
Мне было бы интересно узнать, будет ли после предоставления подсказки выполнять запрос без подсказки, изменил ли QP свой план сканирования этого индекса. Я сомневаюсь, что это проблема кардинальности с 10-миллионными записями, но он никогда не говорил нам о самой колонке и о том, что она представляет.
keithwarren7 12.12.2008 13:07:23

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

0
11.12.2008 21:27:20
Ты хоть представляешь, какой эффект это даст? Как вы можете сказать «вероятно»? Насколько вероятно? Сколько усилий они должны потратить? Как бы они взвесили, хорошая ли это идея? Это звучит очень похоже на «попробуй это, попробуй это».
dkretz 11.12.2008 21:33:25
Это будет иметь эффект, но я не могу сказать вам, сколько. Лучше ли использовать HashTable или последовательно выполнять поиск по списку при поиске элемента? Разделяй и властвуй. Это CS1.
Brad Barker 11.12.2008 21:38:24
CS1 не означает, что вам, вероятно, следует разбивать большие таблицы и индексы, потому что это может помочь.
dkretz 11.12.2008 21:46:59
Это будет больно на вставках, но вы говорите мне, что это не поможет на чтениях? Шутки в сторону?
Brad Barker 11.12.2008 21:48:13
Я говорю, что вопрос в том, насколько сильно больно и как сильно помочь. Это не стоит всех затрат на реализацию и поддержку для получения 0,05% прибыли; что вполне возможно. Я говорю, что ваше предложение является довольно случайным, если вы не подходите и не сравниваете его и просто говорите «вероятно», как если бы оно было очевидным.
dkretz 11.12.2008 22:09:14

Используйте Показать план выполнения в SQL Query Analyzer, чтобы увидеть, используется ли индекс.

Вы также можете попробовать сделать его кластерным индексом, если это еще не сделано.

1
11.12.2008 21:44:15
 select top 10000 

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

0
11.12.2008 23:19:38