Каковы методы определения ненужных столбцов в покрывающем индексе? - PullRequest
Новая
       44

Каковы методы определения ненужных столбцов в покрывающем индексе?

1 голос
/ 09 октября 2009

Какие существуют методы для определения лишних столбцов в покрывающих индексах: столбцы, по которым никогда не выполняется поиск, и, следовательно, они могут быть извлечены в Включения или даже полностью удалены без влияния на применимость индекса?

Ответы [ 2 ]

2 голосов
/ 09 октября 2009

Чтобы уточнить вещи
Идея индекса покрытия состоит в том, что он также включает столбцы, которые не могут быть найдены (используется в предложении WHERE и т. Д.), Но могут быть выбраны (часть списка столбцов SELECT ).

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

  • За репрезентативный период времени запишите все запросы, выполняемые на сервере (или в нужной таблице)
  • Отфильтровывать (с помощью регулярных выражений) запросы, не связанные с базовой таблицей
  • Для остальных запросов получите план запроса; отменить запросы, не включающие рассматриваемый индекс
  • Для оставшихся запросов, или, вернее, для каждого «шаблона» запроса (многие запросы совпадают, но для значений критериев поиска) составьте список столбцов из индекса, которые либо находятся в предложении select, либо where (или в РЕГИСТРИРУЙТЕСЬ ...)
  • столбцы из индекса, не найденные в этом списке, безусловно хороши.

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

Вышеуказанный клинический подход довольно непривлекателен. Аналитический подход может быть предпочтительнее :

Поиск всех запросов «шаблонов», которые могут использоваться во всех приложениях, использующих сервер. Для каждого из этих шаблонов найдите те, которые могут использовать индекс покрытия. Это (снова несколько дыр ...) запросов, которые:

  • включает ссылку на базовую таблицу
  • ни в коем случае не ссылаться на столбец из базовой таблицы, который не является столбцом в индексе
  • не использовать критерии поиска из базовой таблицы, которые являются более избирательными, чем столбцы индекса (в том же порядке ...)

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

0 голосов
/ 09 октября 2009

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

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

...