Как узнать, какие рекомендации по индексам SQL Server 2005 следует реализовать, если таковые имеются?

Question

Мы находимся в процессе обновления одного из наших экземпляров SQL Server с 2000 по 2005 год. Я установил информационную панель производительности (http://www.microsoft.com/downloads/details.aspx?FamilyId=1d3a4a0d-7e0c-4730-8204-e419218c1efc&displaylang=en) для доступа к некоторым отчетам высокого уровня. Один из отчетов показывает отсутствие (рекомендуется индексы. Я думаю, что он основан на некотором системном представлении, которое поддерживается оптимизатором запросов.

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

Answer 1

Совет, который вы получили, верен. Попробуйте их всех по одному.

НЕТ замены для тестирования, когда дело доходит до производительности. Если вы не докажете это, вы ничего не сделали.

Answer 2

Первое, что нужно знать:

При обновлении с 2000 на 2005 (с помощью отсоединения и подключения) убедитесь, что вы:

1. Установить совместимость на 90
2. Перестройте индексы
3. Запустить обновление статистики при полном сканировании

Если вы этого не сделаете, вы получите неоптимальные планы.

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

Answer 3

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

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

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