Читать интересную книгу Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - Хелен Борри

* существует ли критерий выбора, и если да, существует ли доступный или подходящий индекс;

* необходимость выполнения сортировок, как промежуточных (для слияния), так и окончательной (для упорядочения и группирования).

Потоки

Применение термина "поток", который возникает при обсуждении оптимизатора, является просто общим способом наименования множества строк. Набор может содержать все строки и столбцы таблицы или это может быть подмножество данных таблицы, ограниченное некоторым образом спецификациями столбцов и условиями поиска. В процессе обработки запроса сервер может из существующего потока создавать новые потоки, такие как внутренний сортированный набор или набор значений подзапроса для сравнения IN(). См. также далее разд. "Реки".

Использование индексов

Сервер Firebird может использовать в запросах индекс для трех видов задач.

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

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

* Сортировка и группирование: если условия в ORDER BY или GROUP BY указывают столбец, который индексирован, то этот индекс будет использован для поиска строк в нужном порядке, а операция сортировки не потребуется.

Формирование двоичного образа потоков

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

Двоичное представление языка

В основе обработчика SQL Firebird лежит его родной язык двоичного представления (Binary Language Representation, BLR) и интерпретатор, состоящий из лексического анализатора, синтаксического анализатора, таблицы символов и генератора кода. Обработчик DSQL и включенные приложения передают BLR оптимизатору, и именно BLR, а не строки анализирует оптимизатор. Может случиться такое, что два разных оператора SQL интерпретируются в идентичные BLR.

! ! !

СОВЕТ. Если вам любопытно, на что похож BLR, вы можете использовать инструмент qli (в каталоге Firebird bin) для просмотра операторов. Запустите qli и выдайте команду SET BLR для включения отображения BLR. Документ по qli в формате PDF может быть загружен с различных сайтов Firebird, в том числе с http://www.ibphoenix.com.

Если у вас есть операторы SELECT в хранимой процедуре или триггере, вы можете просмотреть их в isql, выдав команду SET BLOB 2 и выбрав столбец

RDB$PROCEDURE BLR из таблицы RDB$PROCEDURES.

. ! .

Соединения без индексов

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

Реки

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

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

Размер конкретной реки находится после того, как будет определена наибольшая ветвь в процессе оценки соединения. Оптимизатор выбирает наибольшую ветвь - максимальное количество пар потоков, которые могут быть соединены напрямую. Предпочитаемый метод доступа- сканирование самого большого потока (в идеале самого левого потока) и просмотр в цикле меньших потоков.

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

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

Примеры планов

Многие графические инструменты администратора базы данных имеют средства для просмотра планов оптимизатора при подготовке оператора. Собственная утилита Firebird isql предоставляет две интерактивные команды для просмотра планов.

Просмотр планов в isqlSET PLAN

В интерактивной сессии isql вы можете использовать SET PLAN С необязательными ключевыми словами ON или OFF для переключения режима отображения плана в начале консольного вывода:

SQL>SET PLAN;

SQL>SELECT FIRST_NAMES, SURNAME FROM PERSON

CON>ORDER BY SURNAME;

PLAN (PERSON ORDER XA SURNAME)

FIRST NAMES

SURNAME

George Stephanie

Abraham Allen

SET STATS

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

SQL>SET STATS ON;

SQL> запускаете ваш запрос>

PLAN..

<вывод>

Current memory = 728316

Delta memory = 61928

Max memory = 773416

Elapsed time =0.17 sec

Buffers = 2048

Reads = 15

Writes = 0

Fetches = 539

SET PLANONLY

Альтернативная команда переключателя SET PLANONLY [ON | OFF] подготавливает оператор и отображает план без выполнения запроса:

SQL>SET PLAN OFF;

SQL>SET PLANONLY ON;

SQL>SELECT FIRST_NAMES, SURNAME FROM PERSON

CON>ORDER BY SURNAME;

PLAN (PERSON ORDER XA_SURNAME)

Если вы собираетесь использовать план оптимизатора в качестве стартовой точки для конструирования пользовательского предложения PLAN, то имейте в виду, что синтаксис выводимого выражения идентичен требуемому синтаксису для выражения плана в операторе[80]. Неудобным является то, что в isql не существует возможности выводить план оптимизатора в текстовый файл.

! ! !

СОВЕТ. Графические инструменты, которые отображают планы, обычно предоставляют средства копирования/вставки.

. ! .

Следующие примеры используют запросы, которые вы сами можете проверить, используя тестовую базу данных employee.fdb, инсталлированную в ваш каталог примеров[81].

Простейший запрос

Этот запрос просто отыскивает все строки из таблицы соответствия в произвольном порядке. Хотя оптимизатор определяет наличие индекса (индекс первичного ключа), он его не использует для поиска:

SQL>SET PLANONLY ON;

SQL> SELECT * FROM COUNTRY;

PLAN (COUNTRY NATURAL)

Упорядоченный запрос

Это все еще простой запрос без соединений:

SQL>SELECT * FROM COUNTRY ORDER BY COUNTRY;

PLAN (COUNTRY ORDER RDB$PRIMARYl)

Оптимизатор выбирает индекс первичного ключа, потому что он имеет запрашиваемое упорядочение; при этом не требуется создание промежуточного потока для сортировки.

Теперь давайте посмотрим, что произойдет, когда мы решим упорядочить тот же самый запрос по неиндексированному столбцу:

SELECT * FROM COUNTRY ORDER BY CURRENCY;

PLAN SORT ((COUNTRY NATURAL))

Оптимизатор выбирает выполнение сортировки, просматривая таблицу COUNTRY В естественном порядке.

Перекрестное соединение

Перекрестное соединение, которое обычно создает бесполезный набор, вовсе не использует критериев соединения:

SQL> SELECT Е.*, P.* FROM EMPLOYEE Е, PROJECT Р;

PLAN JOIN (Р NATURAL,Е NATURAL)

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