Оптимизация запроса (инструкций SELECT)

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

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

Компонент СУБД, ответственный за такую деятельность, называется оптимизатором запросов.

Задачей оптимизатора запросов (или просто оптимизатора) является рассмотрение множества возможных стратегий выполнения поиска требуемых в запросе данных и выбор наиболее эффективной стратегии.

Выбранная стратегия называется планом выполнения запроса.

Оптимизатор принимает свои решения с учетом таких факторов, как: насколько велики по размерам таблиц, вовлеченные в запрос, какие существуют индексы и какие логические операции (and, or, not) используются в предложении where. Обычно такие факторы называются статистическими данными.

Процесс выполнения операторов SQL может быть условно разделен на 5 этапов:

Рис. Процесс выполнения операторов SQL

1. На первом этапе выполняется синтаксический анализ оператора SQL. На этом этапе проверяется корректность записи SQL-оператора в соответствии с правилами синтаксиса. Проверяется синтаксис запроса, сам запрос преобразуется в дерево.

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

3. На этом этапе проводится оптимизация запроса. В качестве входных оптимизатор запросов получает скомпилированное дерево запроса, которое было сгенерировано на предыдущем шаге, и рассматривает стратегии доступа, прежде чем принять решение, как следует обрабатывать данный запрос. СУБД проводит разделение целостного запроса на ряд минимальных операций и оптимизирует последовательность их выполнения с точки зрения стоимости выполнения запроса. На этом этапе строится несколько планов выполнения запроса и выбирается из них один — оптимальный для данного состояния БД.

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

4. На четвертом этапе СУБД генерирует двоичную версию оптимального плана запроса, подготовленного на этапе 3. Двоичный план выполнения запроса в СУБД фактически является эквивалентом объектного кода программы. Скомпилированные планы запроса сохраняются в части памяти SQL Server, называемой кэшем плана.

5. На пятом этапе СУБД реализует (выполняет) разработанный план, тем самым выполняя оператор SQL.

Перечисленные этапы отличаются по числу обращений к БД и по процессорному времени, требуемому для их выполнения.

Синтаксический анализ проводится очень быстро, он не требует обращения к системным каталогам БД.

Семантический анализ уже требует работы с базой метаданных, то есть с системными каталогами БД, поэтому при выполнении этого этапа происходит обращение к системному каталогу и серьезная работа с ним.

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

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

Производительность запроса для ее улучшения может быть проанализирована с помощью просмотра планов выполнения запроса (имеются специальные средства).

Оптимизация запроса (инструкций SELECT)

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

Выполняющий это компонент называют оптимизатором запросов.

Входные данные оптимизатора состоят из самого запроса, схемы базы данных (определений таблиц и индексов) и статистики базы данных.

Выходные данные оптимизатора — план выполнения запроса, иногда называемый планом запроса или просто планом.

Входные и выходные данные оптимизатора запроса при оптимизации одиночной инструкции SELECT проиллюстрированы на рисунке.

Инструкция SELECT определяет только следующее.

· Формат результирующего набора. Он указан, главным образом, в списке выборки. Однако другие предложения, например ORDER BY и GROUP BY, также затрагивают конечную форму результирующего набора.

· Таблицы, которые содержат исходные данные. Указываются в предложении FROM.

· Как таблицы логически связаны с целями инструкции SELECT. Это определяется в спецификациях соединения, которые могут появляться в предложении WHERE или в предложении ON, следующем за предложением FROM.

· Условия, которым строки в исходных таблицах должны соответствовать для выбора их инструкцией SELECT. Указываются в предложениях WHERE и HAVING.

План выполнения запроса представляет собой определение следующего.

1. Последовательности, в которой происходит обращение к исходным таблицам.

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

Например, если инструкция SELECT ссылается на три таблицы, сервер базы данных сначала может обратиться к TableA, использовать данные из TableA для извлечения соответствующих строк из TableB и затем использовать данные из TableB для извлечения данных из TableC.

Другие последовательности, в которых сервер базы данных может обращаться к таблицам:

TableC, TableB, TableA или

TableB, TableA, TableC или

TableB, TableC, TableA или

TableC, TableA, TableB

Поиск по сайту: