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

Question

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

Answer 1

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

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

• В течение репрезентативного периода времени запишите все запросы, выполняемые на сервере (или в нужной таблице).
• Отфильтровывать (с помощью регулярных выражений) запросы, не связанные с базовой таблицей
• Для оставшихся запросов получите план запроса;отбрасывайте запросы, не связанные с рассматриваемым индексом
• Для остальных запросов, или, скорее, для каждого "шаблона" запроса (многие запросы одинаковы, но для значений критериев поиска), составьте список столбцов из индекса, которые находятся либо в предложении select, либо where (или в JOIN ...)
• столбцы из индекса, не найденные в этом списке, положительно подходят для использования.

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

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

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

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

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

Answer 2

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

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