8.8.5.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 сказать оптимизатору определять значение автоматически.