Оптимизация, основанная на вычислении стоимости

Оптимизация, основанная на вычислении стоимости запроса (cost-based optimization), аналогична оптимизации, основанной на правилах, за исключением того, что оптимизатор на основе вычисления стоимости использует статистическую информацию для выбора наиболее эффективного плана выполнения запроса. Стоимость каждого альтернативного плана выполнения запроса оценивается с помощью статистики, такой как число строк в таблице и числа и распределения значений колонки таблицы. Формулы стоимости обычно учитывают количество ввода/вывода и время CPU, необходимое для выполнения плана запроса. Такая статистика хранится в системном каталоге и поддерживается СУБД.

Для понимания того, как статистика может быть использована для выбора плана выполнения запроса, рассмотрим следующий запрос к таблице CUSTOMER (ПОКУПАТЕЛЬ):

SELECT CUST_NBR, CUST_NAME
FROM CUSTOMER
WHERE STATE = "FL";

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

Подход к оптимизации, основанный на вычислении стоимости, сегодня представляет определенное искусство в технике оптимизации запросов. Большинство реляционных СУБД применяют оптимизаторы, основанные на вычислении стоимости.

Последовательность шагов оптимизации запросов

Несмотря на то, что оптимизаторы запросов современных реляционных СУБД различаются по сложности и принципам создания, все они следуют одним и тем основным этапам в выполнении оптимизации запроса.

• Синтаксический разбор запроса (parsing). Оптимизатор сначала разбивает запрос на его синтаксические компоненты, проверяет ошибки в синтаксисе и затем преобразует запрос в его внутреннее представление для дальнейшей обработки.
• Преобразование (conversion). Далее оптимизатор применяет правила преобразования запроса для преобразования его в формат, оптимальный с точки зрения синтаксиса.
• Построение альтернатив (Develop alternatives). Когда запрос проходит синтаксическую оптимизацию, оптимизатор разрабатывает альтернативы для его выполнения.
• Создание плана выполнения запроса (Сreate execution plan). Окончательно оптимизатор выбирает лучший план выполнения запроса, либо следуя набору эвристических правил, либо вычисляя стоимость для каждой альтернативы выполнения.

Так как шаги 1 и 2 имеют место независимо от действительных данных, находящихся в таблицах, нет необходимости повторять их, если запрос не требует перекомпиляции. Следовательно, большинство оптимизаторов будут сохранять результаты 2-го шага и использовать его снова, когда они переоптимизируют запрос в другой раз.

Обзор оптимизатора запросов

В следующих разделах лекции на примере оптимизатора запросов СУБД SQLBase мы расскажем об общих принципах работы оптимизаторов. Оптимизатор запросов SQLBase (далее просто - оптимизатор) является специфической реализацией оптимизатора, основанного на вычислении стоимости, который принимает свои решения о выборе пути доступа на основе оценок потенциальной стоимости, связанной с выполнением конкретного плана доступа.

Основой этих стоимостных оценок является статистика, содержащаяся в системном каталоге SQLBase и областях управления базой данных. Преимущество такого подхода состоит в том, что решения о плане доступа могут быть сделаны на очень новой информации, связанной с действительным содержанием базы данных. Насколько нова и точна эта информация, зависит от процедур, которым вы следуете в администрировании вашей базы данных.

Также будут изложены основы реализации реляционных операций SQL, с последующим изложением методов, которые использует SQLBase при фактическом выполнении этих операторов. Это множество методов, называемое физическими операторами (physical operators), является последовательностью действий, которые рассматривает оптимизатор, когда строит план доступа.

Сначала мы рассмотрим, как выполняются физические операторы. Мы также кратко суммируем основные факторы, включая стоимость каждого из них (обычно в терминах ввода/вывода). В завершении будет объяснена структура плана доступа, с акцентом на эвристиках, используемых оптимизатором при построении множества планов доступа, для которых выполняется анализ стоимости.

На протяжении всех остальных трех частей примеры, которые иллюстрируют операции оптимизатора, обычно используют команду SELECT. Однако следует помнить, что все команды манипулирования данными (DML), т.е. команды INSERT, UPDATE, DELETE, обрабатываются оптимизатором.

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

Вторым преимуществом использования команды SELECT для примеров является то, что выполнение этой команды приводит к созданию результирующего множества, которое визуально показывает окончательный результат обработки запроса. Это является контрастом по сравнению с другими командами DML, которые изменяют состояние базы данных, но эти изменения не являются визуальными за исключением сообщений об ошибках или значениях встроенных переменных. Только команды SELECT будут визуально отражать эти изменения в содержании базы данных, сделанные при выполнении других команд DML.