! ! !
СОВЕТ. Графические инструменты, которые отображают планы, обычно предоставляют средства копирования/вставки.
. ! .
Следующие примеры используют запросы, которые вы сами можете проверить, используя тестовую базу данных 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)
Оно просто сливает каждый поток в левой части с каждым потоком правой части. Оптимизатор не использует индексы. Однако этот пример полезен в качестве введения в соединение между алиасами двух таблиц в спецификации соединения и их использовании в плане.
Алиасы, указанные в запросе, используются в плане, выводимом оптимизатором. Для совместимости при создании пользовательского плана хорошей идеей является использование того же способа идентификации таблиц, как и в запросе. При этом, несмотря на то, что синтаксический анализатор не допускает смешивания идентификаторов таблиц и их алиасов в запросах, предложение PLAN допускает любое смешивание[82]. Например, следующий вариант является приемлемым. Обратите внимание, что оптимизатор допускает использование и идентификаторов таблиц в предложении PLAN.
SQL> SELECT Е.*, P.* FROM EMPLOYEE E, PROJECT P
CON> PLAN JOIN (PROJECT NATURAL, EMPLOYEE NATURAL);
PLAN JOIN (P NATURAL, E NATURAL)
Такое соединение денормализует отношение один-ко-многим - каждый служащий имеет одну или более записей истории заработной платы:
SELECT Е.*, S.OLD_SALARY, S.NEW_SALARY
FROM EMPLOYEE E
JOIN SALARY_HISTORY S
ON S.EMP_NO = E.EMP_NO;
PLAN JOIN (S NATURAL, E INDEX (RDB$PRIMARY7))
Оптимизатор выбирает цикл по (потенциально) самому длинному детальному потоку для поиска релевантных строк с использованием индекса уникального первичного ключа таблицы EMPLOYEE. В этом примере либо количество строк в каждой таблице будет приблизительно равным, либо количество строк в таблице SALARY_HISTORY не превысит количество строк в таблице EMPLOYEE в той мере, чтобы не достичь преимуществ уникального индекса в качестве ключа соответствия. Это внутреннее соединение, и оптимизатор разумно предполагает, что именно правый поток определит размер реки.
Давайте посмотрим, как оптимизатор трактует те же самые потоки, когда соединение является внешним левым:
SELECT Е. *, S.OLD_SALARY, S.NEW_SALARY
FROM EMPLOYEE E
LEFT JOIN SALARY_HISTORY S
ON S.EMP_NO = E.EMP_NO;
PLAN JOIN (E NATURAL, S INDEX (RDB$FOREIGN21))
В этот раз одна строка будет возвращена для каждой строки правого потока, независимо от того, будет ли существовать соответствующий ключ в управляющем потоке. Размер реки здесь не имеет значения, поскольку внешние соединения однозначно определяют, какая таблица должна быть в левой стороне, чтобы по ней проводить цикл просмотра. Это алгоритм внешнего соединения, который определяет метод доступа, не измеряющий потоки. С таблицей EMPLOYEE В левой части не существует возможности создать внешнее соединение путем просмотра таблицы SALARY_HISTORY с поиском в EMPLOYEE.
Поскольку оптимизатор не делает выбора относительно того порядка, в котором будут соединяться потоки, он просто выбирает наиболее подходящий индекс из SALARY_HISTORY.
В следующем примере размер таблицы не виден при использовании индекса уникального первичного ключа. Таблица DEPARTMENT содержит 21 строку, таблица PROJECT - 6 строк, и оптимизатор выбирает меньший индекс внешнего ключа для оптимизации поиска соответствия по большей таблице:
SELECT * FROM DEPARTMENT D
JOIN PROJECT P
ON D.MNGR_NO = P. TEAM_LEADER ;
PLAN JOIN (D NATURAL,P INDEX (RDB$FOREIGN13))
Использование индексированных спецификаций упорядочения может повлиять на то, как оптимизатор выбирает навигацию по потокам. Возьмем следующий пример:
SQL> SELECT P.*, E.FULL_NAME FROM PROJECT P JOIN EMPLOYEE E
ON E.EMP_NO = Р. TEAM_LEADER ORDER BY P.PROJ_NAME ;
PLAN JOIN (Р ORDER RDB$11, E INDEX (RDB$PRIMARY7))
Уникальный индекс для EMPLOYEE выбирается по причине неявного условия фильтра в критерии соединения. Запрос сокращает количество служащих, которые не являются руководителями, а уникальный индекс позволяет исключить сканирование таблицы EMPLOYEE. Выбор индекса фильтрации может также повлиять на необходимость использования навигационного индекса в PROJ_NAME для сортировки[83].
Оптимизатор выбирает индекс правой стороны, потому что правый поток будет того же размера, что и левый или (потенциально) большего размера. Опять же, оптимизатор не может сказать, что это отношение является отношением один к одному. Столбец PROJ_NAME, задающий порядок выходного набора, имеет уникальный индекс, созданный ограничением UNIQUE, чтобы использовать для сортировки, и оптимизатор выбирает этот индекс. Индекс сортировки появляется в плане первым, указывая серверу на необходимость сортировки левого потока перед тем, как он будет отыскивать соответствие ключа соединения в правом потоке.
Таблицы в следующем запросе являются неиндексированными копиями таблиц PROJECT и EMPLOYEE (см. сноску 4 ранее в этой главе):
SQL> SELECT PI.*, EL. FULL_NAME FROM PROJECT1 PI JOIN EMPLOYEEL EL ON EL.EMP_NO = PL.TEAM_LEADER ORDER BY PI. PROJ_NAME;
PLAN SORT (MERGE (SORT (EL NATURAL) , SORT (PI NATURAL)))
Потоки с обеих сторон будут сортироваться, а затем сливаться, полученная река снова будет сортироваться, потому что ни один из потоков не имеет требуемого порядка сортировки.
Рассмотрим тройное эквисоединение в следующем примере:
SQL> SELECT P.PROJ_NAME, D.DEPARTMENT, PDB. PROJECTED_BUDGET FROM PROJECT P
JOIN PROJ_DEPT_BODGET PDB ON P.PROJ_ID = PDB.PROJ_ID JOIN DEPARTMENT D ON PDB.DEPT_NO = D.DEPT_NO;
PLAN JOIN (D NATURAL, PDB INDEX (RDB$FOREIGN18), P INDEX (RDB$PRIMARY12))
Поскольку доступно множество подходящих индексов, оптимизатор выбирает метод доступа JOIN. Индекс, связывающий поток PDB с таблицей DEPARTMENT, будет использован для выбора потока DEPARTMENT. При обработке результирующей реки и потока PROJECT эквисоединение между первичным ключом таблицы PROJECT и большей по размеру (потенциально) реки дает возможность формировать реку с использованием индекса первичного ключа PROJECT для выборки данных из реки.
81
Поскольку база данных примера не имеет таблиц без индексов, некоторые примеры в этом разделе используют специально описанные неиндексированные версии таблиц EMPLOYEE, PROJECT и DEPARTMENT, названные EMPLOYEE1, PROJECT1 и Departments соответственно. Скрипт с именем NO_INDEXES.SQL для создания этих таблиц может быт загружен с http://www.apress.com.
82
Другой причиной использования алиасов при задании запросов и планов является то, что, скорее всего, подобная согласованность будет поддерживаться в следующих версиях Firebird.
83
"Сортировка по индексу" является недоразумением. Предложение ORDER В плане запроса дает указания серверу читать поток вне порядка хранения (то есть с использованием навигационного индекса для поиска строк). Этот метод может работать только с управлением потоком в цикле и создавать предварительно упорядоченный результат. Поскольку ORDER может быть использован только для левого потока в соединении, любое правило, которое влияет на упорядоченность соединения - например, внешнее соединение, которое не дает возможность потоку быть самым левым - будет иметь преимущество.