Сердцем реляционной системы баз данных является оптимизатор запросов

Оценить
(0 голоса)

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

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

Роль оптимизатора запросов заключается в определении наиболее эффективного способа получения и обработки данных, необходимых для удовлетворения запроса. Подход, используемый оптимиза тором, именуется по-разному: QP (query plan n.wu запроса), QEP (query execution plan - план выполнения запроса), или план изложения. Эффективность плана запроса, выбираемого оптимизатором, важна для запросов OLTP. легковесных по своей природе, и крайне необходима для запросов DSS, которые могут впустую расходовать большое количество ресурсов ЦП и ввода/вывода.

Здесь нам может прийти на помощь следующая аналогия. Вы можете добраться из Калифорнии в Нью-Йорк самолетом, автобусом, автомобилем, по морю, велосипедом или же пешком. Если необходим самый быстрый способ, то вам подойдет перелег, который, однако, не является самым дешевым способом. Точно также могут использоваться и различные методы для выполнения запроса. Оптимизатор может решить, что необходимо выполнить сканирование таблицы (то есть, чтение всей таблицы и исключение строк, которые не являются необходимыми) или получить данные по индексу.

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

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

Какой бы алгоритм не использовался, предопределенные стратегии оптимизации влияют на выбор, произведенный оптимизаторами запросов баз данных. Иногда системы баз данных предусматривают для пользователей возможность воздействия на эти стратегии путем выбора уровня оптимизации запросов. Уровни оптимизации отличаются по итоговому объему работ, затрачиваемых на поиск наиболее подходящего плана запроса.

Запрос, согласно которому необходимо получить 5% строк из таблицы, содержащей 100000 страниц, может помочь в качестве иллюстрации альтернативных планов запросов. Если доступен подходящий индекс, то логически можно прийти к его использованию для выявления необходимых строк и их поиска в таблице.

Вы могли прийти к выводу о том, что на основании индексного доступа к таблице понадобятся 5000 табличных страниц плюс меньшее количество страниц из индекса-куда меньше страниц, чем при сканировании таблицы. Проблема заключается в том, что для запроса необходимо 5% строк, а не 5% блоков. Если размер страницы базы данных составляет 16 Кбайт, а средний размер строки таблицы - 256 байт, то каждая страница в среднем будет содержать 64 строки, а таблица будет иметь в обшей сложности 6400000 строк. Получение 5% строк на самом деле будет заключаться в произвольном считывании 320000 строк данных по индексу. В зависимости от эффектов кэширования это может означать чтение вплоть до 320000 страниц данных плюс страницы индексов.

В действительности может быть более эффективно и куда быстрее получить все 100000 страниц путем сканирования таблицы и отбросить те строки, которые не являются необходимыми. Оптимизатор должен произвести расчеты и определить наилучшую альтернативу.

Подробнее в этой категории: Компиляция запросов »
Компиляция запросов
Факторы, негативно влияющие на оптимизацию запроса
Методы оптимизации
Доступ к таблице
Порядок объединения таблиц

Добавить комментарий


Защитный код
Обновить