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

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

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

SELECT ...

WHERE PARENT_COUNTRY = 'AD'

Если эта база данных распространяется в Австралии (код страны 'AO'), то селективность PARENT_COONTRY будет настолько низкой, что полностью обрушит производительность, однако вы привязаны к обязательному индексу. Чтобы оптимизатор проигнорировал индекс, измените предикат поиска на [85] :

SELECT ...

WHERE PARENT COUNTRY = 'AU' OR 1=1

Получение "картины" соединения не является точной наукой, в процессе работы вы получите интуитивное понимание создания спецификаций соединений. Однако с этой техникой борются многие люди. Для всех спецификаций запросов, особенно для запросов к множеству таблиц, секрет заключается в добросовестном их проектировании. Если у вас мало опыта в SQL, не полагайтесь на инструменты CASE или утилиты конструирования запросов, чтобы научиться их создавать. Это классическая ситуация: пока вы не приобретете опыт, вы не сможете оценить, насколько глупы данные инструменты. Если вы всегда полагаетесь на тупые инструменты, вы никогда не приобретете интуицию.

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

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

В этой главе мы рассмотрим синтаксис и правила задания запросов, которые выводят упорядоченные и сгруппированные наборы.

Наборы, заданные оператором SET, по умолчанию читаются в произвольном порядке. Часто, особенно при отображении данных для пользователя или при печати отчетов, вам нужен определенный вид сортировки. Ясно, что список телефонов будет более полезным, если фамилии будут находиться в алфавитном порядке. Группы чисел по продажам или тестовые результаты более понятны, если они упорядочены, сгруппированы и просуммированы. В SQL существует два предложения по заданию формирования выходных наборов.

Предложение ORDER BY используется для сортировки наборов в возрастающем или убывающем порядке по одному или большему количеству столбцов. Предложение GROUP BY может разделять набор на вложенные группы, или уровни, в соответствии со столбцами из списка SELECT и (по желанию) выполняя агрегатные вычисления на множестве числовых столбцов в границах группы.

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

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

SELECT [FIRST m] [SKIP N] | [DISTINCT | ALL ]

{<список-столбцов>}

FROM <спецификация-таблицы>

[WHERE <условие-поиска>]

[GROUP BY <элемент-группировки> [COLLATE последовательность-сортировки]

[, <элемент-группировки> [COLLATE последовательность-сортировки ]...]

[HAVING <условие-поиска>]

[UNION [ALL] <выражение-выбора>]

[PLAN <выражение-плана>]

[ORDER BY <список-сортируемых-элементов>]

[FOR UPDATE [OF столбец [,столбец ...]] [WITH LOCK]];

Запросы с предложениями ORDRE BY и GROUP BY "паркуют" промежуточные наборы для дальнейших операций сортировки во временном хранилище. Рекомендуется иметь доступную память, приблизительно в 2.5 раза превышающую размер самой большой таблицы, которую вы будет сортировать. Версии Firebird 1.5 и выше могут конфигурировать память для сортировки в RAM; всем версиям нужно иметь временное дисковое пространство для использования в этих операциях.