Мысли о создании индекса для SQL Server на случай отсутствия индексов

Я работаю над настройкой производительности моей базы данных SQL Server 2008 и использую выходные данные различных DMV для определения отсутствующих индексов, индексов, которые не используются, и т. Д.

В основном я использую эти 3 сценария (с SQLServerCentral.com), которые полагаются на данные DMV, которые предоставляет SQL Server:

Ultimate Missing Index Finder

Ultimate Duplicate Index Finder

The Ultimate Index Usage Reporter

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

Поэтому я хотел узнать мнение сообщества и посмотреть, смогут ли люди ответить на несколько вопросов о чтении результатов DMV и структурировании новых индексов.

Имеет ли значение порядок включения столбцов в индексе?

Примите следующие два предложения индекса. Что бы вы сделали, чтобы сделать так, чтобы одна подошла обоим?

object_name equality_columns                    inequality_columns              included_columns
    Appointment [FranchiseId], [AppointmentTypeId]  [CustomerId], [ApptDateTime]    NULL
    Appointment [FranchiseId], [AppointmentTypeId]  [ApptDateTime]                  [CustomerId]

Если у меня есть много предложений по индексам с одинаковыми полями равенства и неравенства, но с разными включенными полями, что лучше: включить больше полей или пойти с меньшим количеством включенных полей? Опять же, цель состоит в том, чтобы создать 1 индекс вместо 3 (если 3 имеют разные включенные столбцы).

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


person Don    schedule 14.01.2009    source источник
comment
Чтобы сделать правильный выбор индексации, вам нужно добавить несколько, а затем протестировать. Если все работает нормально, то остановись. Если это не сработает, попробуйте альтернативные варианты. Трудно сказать, что есть одно лучшее решение. Это действительно зависит от модели использования.   -  person Ken Yao    schedule 14.01.2009
comment
Определенно понял. Я собираюсь сначала внести свой первый раунд изменений в довольно неиндексированную базу данных. В своей первой итерации я пытаюсь сузить, скажем, 19 предложений индекса для таблицы до как можно меньшего числа. Мой план определенно состоит в том, чтобы добавить, посмотреть, а затем еще раз оценить результаты.   -  person Don    schedule 14.01.2009


Ответы (1)


Порядок имеет значение для проиндексированных столбцов, но не для включенных столбцов. Это связано с тем, что для поиска используются только ключевые столбцы.

Вы должны «читать между строк» ​​большую часть документации, но именно это подразумевается в эта статья BOL

Это обсуждение немного больше явный порядок изложения не важен.

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

person BradC    schedule 14.01.2009
comment
Для полной ясности: весь смысл включенных полей в индекс состоит в том, что они могут изменяться, не влияя на индекс. Когда эти значения меняются, вам не нужно перемещать запись в индексе, что снижает накладные расходы на обновления. - person Brent Ozar; 15.01.2009
comment
Так что насчет двух примеров предложений, что вы думаете, ребята? Как бы вы структурировали это в один индекс, учитывая различия в столбцах неравенства? - person Don; 15.01.2009