Каждый запрос к базе начинается исполнением не с данных, а с решения. Оптимизатор рассматривает поданный текст, перечисляет допустимые способы его исполнить, оценивает стоимости и выбирает кандидата победителя. Именно здесь решается, пойти ли по индексу или прочитать таблицу целиком, соединять ли хэшем или вложенными циклами, сортировать ли в памяти или на диске. Понимание этой машины отличает инженера, который пишет хинты наугад, от инженера, который пишет запросы, исполняемые за микросекунды.
Как оптимизатор превращает запрос в план
Текст запроса сначала разбирается и нормализуется. Логические эквиваленты переписываются: подзапросы по возможности выпрямляются в соединения, условия приводятся к канонической форме, константы вычисляются заранее. Затем в игру вступает генерация альтернатив: для каждой таблицы перебираются доступные пути доступа, для каждой пары таблиц перебираются порядки соединения, для каждой агрегации способы её материализации.
Космос альтернатив огромен: для десятка таблиц число порядков соединений факториально. Полнопереборный лобовой поиск недоступен, и движки применяют динамическое программирование с отсечением, эвристики, а при чрезмерной ширине задачи рандомизированные стратегии выбора. Результат это компромисс между долгой оптимизацией и быстрой сдачей плана в исполнение.
Каждая альтернатива оценивается в виртуальных единицах стоимости. Модель учитывает страницы чтения, процессорную цену на строку, объёмы промежуточных наборов и коэффициенты дисковой скорости случайного доступа относительно последовательного. Цена не является секундами, она используется только для сравнения планов между собой.
Форма результата это дерево операторов. Узлы держат алгоритмическое решение: последовательный скан, индексный скан, битовая карта, сортировка, хэш агрегация. Исполнитель просто обходит дерево и получает строки от нижних операторов к верхним. План укладывается в линейную развёртку и нередко сохраняется в кэше повторно используемых запросов.
Готовность плана к переиспользованию это отдельная дисциплина. Общие запросы планируются единожды и хранятся в кэше под ключом текста и параметров, но каждый специфический вопрос, отличающийся формой условия, либо готовит новый план, либо наследует общий с соответствующим устареванием при смене распределения значений. Проверка состояния этого кэша становится разделом административного осмотра, потому что разросшийся или сбитый кэш планов способен косвенно замедлять решение новых запросов.
Изменение одного предиката способно перекрасить дерево кардинально, и оттого правильная работа оптимизатора это не гарантия оптимальности в математическом смысле, а стабильное качество средних решений при разумной цене самого планирования.
Статистика как дыхание планировщика
Рейтинг альтернатив опирается на статистику о данных. Гистограммы значений колонок говорят, сколько строк подпадает под конкретный предикат. Число различных значений помогает оценить размеры соединений. Корреляции физического порядка с логическим определяют выгоду индексных обходов. Эти числа собираются анализом таблиц и живут в системных каталогах.
Устаревшая статистика это главный приговор деградирующих продакшн баз. Таблица выросла на порядок, статистика осталась вчерашней, и оптимизатор продолжает считать подзапрос дешёвым на пустых числах. Диагностика таких случаев распознаётся мгновенно по расхождению между оценкой числа строк в плане и фактическим значением: разница в два три порядка указывает именно на отставание статистика.
Регламентные задания обновления статистики это недорогое здоровье системы. Крупные загрузки должны завершаться явным анализом. Автоматические обновления работают по порогам изменений столбцов, и администратору следует знать эти пороги, потому что редко меняющаяся, но растущая таблица может жить между срабатываниями с устаревшей картой распределений.
Современные движки умеют расширять статистику корреляциями между колонками и составными выражениями, но эти дополнительные структуры заводятся персонально и требуют понимания, где именно планировщик ошибается системно. Количество не достоинство: точность оценки функции от предиката важнее обилия собранных чисел.
Лечение ошибочных оценок начинают с сравнения ожидаемого и фактического числа строк через анализирующее исполнение запроса, а не с перепиской условий запроса вслепую, что является частым и разрушительным рефлексом.
Индекс против полного сканирования в борьбе моделей
Выбор между чтением индексом и простым сканированием решается через селективность предиката и цену случайного доступа. Точечная выборка по ключу отдаёт победу индексу безоговорочно, выборка восьмидесяти процентов таблицы отдаёт сканированию. Между ними лежит серая зона, в которой оптимизатор решает по интегральной стоимости.
Кластерность данных влияет на шансы индекса в спорных случаях. Если порядок строк на диске совпадает с порядком ключа, чтение по индексу упорядочено по файлам и дёшево; если порядок хаотичен, каждый ключ это случайный прыжок, и стоимость запредельная. Метрика корреляции между логическим и физическим порядком напрямую учитывается при подсчёте.
Кэширование в памяти вторгается в расчёт тоже. Попадание таблицы в shared buffers понижает цену страницы, и оптимизатор на разумных прошивках учитывает это через коэффициент эффективности кэша. Система с жирной памятью смещается к индексному доступу, потому что случайные чтения обходятся недорого.
Дополнительный ход это использование битовых карт: индекс сканируется один раз, позиции строк собираются в битовую маску, и таблица читается по позициям один последовательный проход. Такой гибрид оказывается дешевле обоих классических путей на средних долях селективности.
На фоне аппарата этого выбора держится практическое правило наблюдения: если таблица недавно обновилась массово, взгляд на неё оптимизатора переоценивается объёмами устаревшего раздела, и следующая волна запросов получает планы ещё хуже обычного. Короткий анализ свежести статистики после массовых загрузок спасает от таких циклов.
Методика верификации решения планировщика в спорных точках это простой ручной перебор: выбирается контрольное значение предиката, прогоняется в обоих режимах принудительным переключением, и выявленные стоимости сообщаются о выборе планировщика сильнее, чем столбец оценочных чисел.
Согласованные планы важнее совершенных. Движок, стабильно выбирающий приемлемые пути, предпочтительнее капризного оптимизатора, который иногда срывается в совершенство и часто падает в провал, и поэтому стабильность решений это отдельная во многих продуктах цикл разработки.
Соединения таблиц и выбор метода
Соединение двух таблиц это операция, которую движок умеет исполнять тремя основными способами. Вложенные циклы читают внешнюю таблицу построчно и ищут партнёра во внутренней по индексу: идеал при малом с почти точечным поиском. Хэш соединение строит хэш таблицу по меньшей стороне и один раз сканирует большую с проверкой совпадений: любимец равных соединений больших наборов. Слияние обходит две сортированные стороны синхронно и сияет на предварительно упорядоченных входах.
Выбор между ними опирается на оценку кардинальности входов и доступности сортированного порядка данных. Ошибка оценки кардинальности это самая горькая ошибка оптимизатора, потому что перепутанный в тысячу раз размер промежуточного набора валит и выбор метода, и размещение ресурсов памяти под хэш таблицу.
Порядок соединений трёх и более таблиц несёт ещё большую ответственность. Соединение, которое выкидывает почти все строки, должно случаться раньше, чтобы последующие этапы работали на малом множестве. Эвристика выбора такого порядка измеряется переносом условий ближе к корню анализа данных, и она снова упирается в качество оценок.
Оптимизатору всегда полезен дизайн схемы, который избавляет его от ответственности быть умным. Денормализация справочников и типовая организация запросов по звёздной схеме уменьшают требования к фантазии планировщика и повышают предсказуемость рабочих решений.
Контрольные вопросы к плану соединения это регулярные маркеры здоровья: верны ли оценка кардинальности, откуда возникла сортировка, справедливо ли использована память. Такие поверки отделяют понимание от слепой веры в приборы.
Глубокий анализ этой механики крупных соединений окупается особенно в аналитических движках, где цена промаха планировщика оценивается сплошь не миллисекундами, а временем занятой полосы данных.
Разбор плана как ежедневный рабочий навык
Аналитик производительности естественным образом читает вывод плана, потому что план это не заученная формула, а развёрнутая стенограмма решений движка. Признаки ловушек ожидают в типичных строках: полное сканирование большой таблицы, превышение фактического времени над оценкой на порядки, неожиданные сортировки на диске при скромном объёме.
Аналитический тренинг это последовательность навыков. Первый шаг это умение узнать формы исполнения по именам узлов и привязать их к стоимости. Второй шаг это построение дисциплины сравнения оценки и факта. Третий это способность объяснить каждое расхождение статистикой, кэшем или структурой запроса.
Эталонный методический порядок работы с медленным запросом стабилен:
- Поймать план с измерением фактических времен и чисел строк по узлам;
- Сравнить оценки с фактами и найти узел максимального расхождения;
- Проверить статистику соответствующих таблиц и колонок в системном каталоге;
- При необходимости обновить статистику и повторить, и только потом касаться структуры индексов и формы запроса.
Изменение формулировки запроса выглядит последним средством, но оно законно, когда семантика диктует движку лишнюю работу: некоррелированные подзапросы и переписывание оконных конструкций порой открывают движку глаза на то, чего он без понуждения не видит.
Ограничения оптимизатора и соблюдение баланса
Планировщик ошибается там, где входные данные превращают задачу в угадывание: переменные параметры сильно меняют селективность от одного исполнения к другому, и план, приготовленный под один параметр, падает при другом. Различные механизмы пересборки планов по фактическому выбору значения существуют для таких случаев, но и они не благодетельны бесплатно, потому что каждый ререплан стоит ресурсов и раздувает кэш планов.
Параметризуемые хинты и профили это механизмы компромисса: вы сужаете пространство выбора там, где знание доопределяет ответ, сохраняя свободу в прочих местах. Злоупотребление хинтами приносит хрупкость под обновления, и регламент их пересмотра должен быть таким же искренним, как у индексов.
Хорошие команды инвестируют время не в подбор планов вслепую, а в инструменты телеметрии: сбор времени выполнения типовых запросов, трекинг собранных планов, предупреждения на расхождениях оценки с фактом. Такая примета институциональной зрелости обеспечивает длительное равновесие системы.
Итоговая позиция остаётся поэтому неизменной: оптимизатор это слепой великан, чьи плечи несут статистика и модель стоимости. Кто накормил его хорошей статистикой и понял его вкусы, тот получает ответы на вопросы базы за миллисекунды вместо секунд, и именно в этом замкнутом взаимодействии строится вся современная производительность реляционных систем.
Дисциплина чтения планов со временем становится рефлексом сильного инженера баз данных: достаточно взгляда на дерево операторов, чтобы понять характер задачи и направление её оптимизации. Это умение приобретается исключительно практикой на живых запросах, и вклад в такую практику это самая надёжная инвестиция в нервную систему команды.