Любые предложения для определения, какие индексы должны быть созданы?

Question

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

Мне любопытно посмотреть, есть ли у кого-нибудь предложения по поиску того, какие столбцы имеет смысл включать в индексы? Я собирался использовать Profiler / DTA или, возможно, создать какой-то запрос, подобный приведенному ниже, чтобы выяснить популярные столбцы.

SELECT name, Count(so.name) as hits, so.xtype
from syscomments as sc
INNER JOIN sysobjects so ON sc.id=so.id
WHERE   sc.text like '%ColumnNamme%'
AND xtype = 'P'
Group by name,so.xtype
ORDER BY hits desc

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

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

Answer 1

Какие-либо предложения для определения, какие индексы должны быть созданы?

Да! Попросите Sql Server сообщить вам.

Sql Server автоматически ведет статистику того, какие индексы он может использовать для повышения производительности. Это уже происходит в фоновом режиме для вас. Смотрите эту ссылку:
http://msdn.microsoft.com/en-us/library/ms345417.aspx

Попробуйте выполнить такой запрос (взято прямо из msdn):

SELECT mig.*, statement AS table_name,
    column_id, column_name, column_usage
FROM sys.dm_db_missing_index_details AS mid
CROSS APPLY sys.dm_db_missing_index_columns (mid.index_handle)
INNER JOIN sys.dm_db_missing_index_groups AS mig ON mig.index_handle = mid.index_handle
ORDER BY mig.index_group_handle, mig.index_handle, column_id;

Только будь осторожен. Я видел, как люди воспринимают отсутствующие представления индексов как Евангелие и используют их, чтобы выдвинуть кучу индексов, которые им на самом деле не нужны. Индексы имеют стоимость , с точки зрения поддержки времени вставки, обновления и удаления, а также использования дискового пространства и памяти. Чтобы реально и точно использовать эту информацию, вы хотите профилировать фактическое время выполнения ваших ключевых процедур как до, так и после любых изменений, чтобы убедиться, что преимущества индекса (по отдельности или в совокупности) не перевешивают затраты. *

Answer 2

Я согласен с bechbd - используйте хороший пример трафика вашей базы данных (запустив трассировку сервера в производственной системе в режиме реального времени, чтобы получить лучший снимок), и позвольте помощнику по настройке базы данных проанализировать эту выборку.

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

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

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

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

Answer 3

Если вы знаете, что все действия происходят из 75 хранимых процедур, я бы использовал профилировщик, чтобы отслеживать, какие хранимые процедуры занимают больше всего времени и называются чаще. Как только вы узнаете, какие из них, посмотрите на эти процедуры и посмотрите, какие столбцы используются чаще всего в разделах Where и JOIN ON. Скорее всего, это те столбцы, в которые вы хотите поместить некластеризованные индексы. Если набор столбцов часто используется вместе, то есть большая вероятность, что вы захотите сделать 1 некластеризованный индекс для группы. У вас может быть много некластеризованных индексов в таблице (250), но вы, вероятно, не хотите помещать в нее больше, чем несколько. Я думаю, вы найдете, что данные ищутся и объединяются в одних и тех же столбцах снова и снова. Помните правило 80/20. Вероятно, вы получите 80% увеличения скорости в первые 20% работы, которую вы делаете. Будет момент, когда вы получите очень небольшое увеличение скорости для добавленных индексов, то есть когда вы захотите остановиться.

Answer 4

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

Answer 5

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