Есть ли какая-либо причина не принимать совет консультанта по настройке ядра СУБД?

Question

Я работаю в команде, обслуживающей веб-приложение .Net с серверной частью SQL Server 2005. В последнее время система работала немного медленно в некоторых местах, поэтому, выполнив все настройки, о которых мы могли подумать (добавление индексов, очистка действительно плохо написанных хранимых процедур и т. Д.), Я выполнил типичную рабочую нагрузку с помощью Tuning Advisor - и он выкладывает огромный список дополнительных индексов и статистики для создания. Моей первоначальной реакцией было сказать «конечно, вы получили это, SQL Server», но есть ли какая-либо причина НЕ делать то, что говорит советник?

Answer 1

Предложены индексы для вычисленных столбцов.

Что тогда не позволяет пользователям вставлять строки в таблицу .

Так что следите за такими вещами.

Answer 2

Я рекомендую этот скрипт SQL; он использует встроенные в SQL 2005 счетчики производительности, чтобы предложить индексы:

SELECT
  migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) AS improvement_measure,
  'CREATE INDEX [missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + CONVERT (varchar, mid.index_handle)
  + '_' + LEFT (PARSENAME(mid.statement, 1), 32) + ']'
  + ' ON ' + mid.statement
  + ' (' + ISNULL (mid.equality_columns,'')
    + CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ',' ELSE '' END
    + ISNULL (mid.inequality_columns, '')
  + ')'
  + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement,
  migs.*, mid.database_id, mid.[object_id]
FROM sys.dm_db_missing_index_groups mig
INNER JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle
WHERE migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) > 10
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC 

Answer 3

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

Если индекс находится в таблице с интенсивным использованием OLAP, вы хотите ограничить свои индексы до 5-10. Для таблиц, которые редко получают вставки или обновления (меньше, чем несколько в секунду), ограничения пространства должны быть единственной проблемой.

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

Answer 4

Есть 2 проблемы с индексами.

1. Индексы занимают место. Пространство дешево, так что обычно это не сильный аргумент против индексов. Однако стоит задуматься.

2. Индексы будут замедлять определенные запросы (такие как вставка, обновление и удаление).

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

Answer 5

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

Answer 6

Будьте осторожны с рекомендациями DROP INDEX - если при захвате трассировки пропущены некоторые запланированные или редкие запросы, они могут пострадать при следующем запуске.

Answer 7

Я думаю, что совет полезен, но, на мой взгляд, он только дает вам попробовать. Вы должны сделать некоторые сравнительные тесты и посмотреть, что помогает, а что нет. Это может занять очень много времени, но, вероятно, того стоит по причинам, указанным Г. Мастросом.

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

Answer 8

Как и все советы, возьмите это с зерном соли и используйте его, чтобы прийти к собственному выводу.