10.9.1 Управление оценкой плана запроса
Задача оптимизатора запросов — найти оптимальный план выполнения SQL-запроса. Поскольку разница в производительности между «хорошим» и «плохим» планами может составлять несколько порядков величины (то есть, секунды против часов или даже дней), большинство оптимизаторов запросов, включая MySQL, выполняют более или менее исчерпывающий поиск оптимального плана среди всех возможных планов оценки запроса. Для запросов с объединением число возможных планов, исследуемых оптимизатором MySQL, растёт экспоненциально с количеством таблиц, упоминаемых в запросе. Для небольшого количества таблиц (обычно менее 7–10) это не проблема. Однако при отправке более сложных запросов время, затраченное на оптимизацию запроса, может легко стать основной узкой точкой в производительности сервера.
Более гибкий метод оптимизации запросов позволяет пользователю контролировать степень исчерпываемости оптимизатора в поиске оптимального плана оценки запроса. Общая идея заключается в том, что чем меньше планов исследует оптимизатор, тем меньше времени он тратит на компиляцию запроса. С другой стороны, поскольку оптимизатор пропускает некоторые планы, он может упустить поиск оптимального плана.
Поведение оптимизатора относительно числа оцениваемых планов можно контролировать с помощью двух системных переменных:
Переменная
optimizer_prune_levelсообщает оптимизатору о пропуске определенных планов на основе оценок количества строк, доступных для каждой таблицы. Наш опыт показывает, что такой «образованный предположение» редко пропускает оптимальные планы и может значительно сократить время компиляции запросов. Именно поэтому этот параметр по умолчанию включен (optimizer_prune_level=1). Однако, если вы считаете, что оптимизатор пропустил лучший план запроса, этот параметр можно отключить (optimizer_prune_level=0) с риском, что компиляция запроса может занять гораздо больше времени. Обратите внимание, что даже с использованием этого эвристического метода оптимизатор по-прежнему исследует примерно экспоненциальное количество планов.Переменная
optimizer_search_depthпоказывает, насколько далеко в «будущее» каждого неполного плана оптимизатор должен посмотреть, чтобы оценить, следует ли его дополнительно расширять. Более низкие значенияoptimizer_search_depthмогут привести к уменьшению времени компиляции запросов на порядки величины. Например, запросы с 12, 13 или более таблицами могут легко потребовать часы и даже дни для компиляции, еслиoptimizer_search_depthблизок к количеству таблиц в запросе. В то же время, если запросы компилируются сoptimizer_search_depthравным 3 или 4, оптимизатор может скомпилировать тот же запрос меньше чем за минуту. Если вы не уверены, какое разумное значение дляoptimizer_search_depth, эту переменную можно установить в 0, чтобы сообщить оптимизатору о самостоятельном определении значения.
© 2025 Oracle
Licensed under the GPLv2 License.