Как принудительное использование индекса может ухудшить запрос после изменения распределения данных?
Принудительное использование индекса фиксирует выбранный путь доступа и не позволяет оптимизатору перейти на более выгодный план. После изменения объёма или распределения данных индексный доступ может потребовать множества обращений к таблице, тогда как полное сканирование или другой индекс стали бы дешевле.
Оптимизатор запросов появился как способ автоматически выбирать план на основе оценочной стоимости операций: сканирования, поиска по индексу, соединений и сортировок. Однако оценки могут быть неточными из-за неполной статистики, сложных условий или особенностей модели стоимости.
Подсказки и механизмы принудительного выбора индекса стали практическим способом временно обойти ошибочное решение оптимизатора. Они полезны как средство диагностики или краткосрочная стабилизация, но связывают запрос с текущими свойствами данных и схемы.
Индекс обычно выгоден, когда условие возвращает небольшую долю строк и чтение найденных данных обходится дёшево. Если после загрузки, удаления или изменения бизнес-распределения условие начинает выбирать значительную часть таблицы, последовательное чтение может стать дешевле множества индексных обращений.
Принудительный индекс опасен тем, что оптимизатор больше не может сравнить этот путь с альтернативами. В результате запрос может замедлиться после роста таблицы, изменения селективности условия, появления нового индекса или изменения физической организации данных.
При обычной оптимизации система оценивает несколько вариантов: индексный поиск с дополнительными чтениями таблицы, сканирование самого индекса, полное сканирование таблицы и другие доступные пути. Для каждого варианта учитываются предполагаемое число строк, стоимость случайного и последовательного чтения, сортировок, соединений и передачи данных между операциями.
Принудительное использование индекса убирает часть этого выбора. Оно не делает индекс более селективным, не уменьшает число фактически подходящих строк и не исправляет устаревшую статистику. Если индекс не покрывает запрос, для каждой найденной записи могут понадобиться дополнительные обращения к таблице; при большом числе строк эти обращения становятся особенно дорогими.
Важно отличать принудительный индекс от рекомендации оптимизатору. В некоторых СУБД подсказка может быть обязательной, в других — учитываться как предпочтение или применяться с ограничениями. Точное поведение зависит от конкретной СУБД, поэтому нельзя переносить семантику подсказок между SQL Server, PostgreSQL, Oracle и другими системами.
Безопасный подход — сначала проверить фактический план, оценки кардинальности, актуальность статистики и стоимость альтернатив. Если оптимизатор ошибся, устойчивее исправить причину: обновить статистику, изменить запрос или индекс, устранить неверные оценки либо использовать плановую фиксацию только после проверки сценариев. Подсказку следует считать локальным контрактом, который нужно повторно проверять после заметных изменений данных и схемы.
Запрос сначала выбирал несколько десятков строк из большой таблицы, и принудительный индекс по клиенту давал быстрый план. Позже один клиент стал отвечать за значительную долю записей. Индексный поиск сохранился, но за ним последовали многочисленные обращения к строкам таблицы, поэтому запрос стал медленнее полного сканирования.
Рассматривались три варианта. Оставить подсказку было просто, но это сохраняло неуниверсальный план. Удалить индекс могло повредить запросам по редким клиентам. Переписать запрос без принуждения и проверить статистику позволяло оптимизатору выбирать путь по текущей селективности, хотя требовало тестирования разных параметров.
Выбрали третий вариант: проверили оценки и фактическое число строк, обновили статистику при необходимости, затем сравнили планы для редких и частых клиентов. Решение признали корректным только после проверки обоих классов параметров; принудительный индекс оставили лишь там, где его преимущество было подтверждено стабильными данными.
1. Всегда ли принудительный индекс означает, что таблица не будет прочитана?
Нет. Если индекс не покрывает запрос, он может использоваться только для поиска ключей, после чего СУБД выполнит дополнительные чтения строк или страниц таблицы. Поэтому наличие операции индексного поиска в плане ещё не означает малый объём физического чтения.
2. Может ли обновление статистики исправить проблему принудительного индекса?
Нет, если подсказка действительно запрещает выбор альтернативного доступа. Статистика может улучшить оценки и обычный план, но принудительный путь останется зафиксированным. Обновление статистики полезно после отказа от подсказки или в СУБД, где подсказка является только предпочтением, а не жёстким требованием.
3. Почему добавление покрывающего индекса иногда не решает проблему принудительного индекса?
Покрытие устраняет дополнительные чтения таблицы, но не делает выбранный индекс оптимальным при высокой доле возвращаемых строк. Если запрос читает большую часть индекса, сортирует результат или участвует в крупном соединении, другой индекс либо последовательное сканирование всё ещё могут иметь меньшую общую стоимость. Покрытие снижает одну составляющую затрат, но не отменяет необходимости сравнивать планы целиком.