Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Следующая упрощенная структура синтаксиса оператора 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; всем версиям нужно иметь временное дисковое пространство для использования в этих операциях.

Оперативная память для сортировки

В версии 1.5 и выше по умолчанию устанавливается размер блока памяти сортировки в 1 Мбайт. Это размер каждого участка памяти RAM, который выделяется сервером вплоть до максимального значения по умолчанию 64 Мбайт для Суперсервера и 8 Мбайт для Классического сервера. Оба эти значения могут быть сконфигурированы с помощью параметров конфигурации sortMemBiocksize и sortMemupperLimit, соответственно, в файле firebird.conf.

! ! !

ВНИМАНИЕ! Не слишком увеличивайте ресурсы памяти для кэша сортировки на машине с Классическим сервером. Поскольку Классический сервер порождает отдельный серверный процесс для каждого соединения, слишком большое значение верхней границы приведет к огромному размеру потребляемой памяти RAM в сильно загруженной системе.

. ! .

Место на диске для сортировки

Если на диске не выделена память для сортировки, то сервер будет сохранять файлы сортировки в каталоге /tmp файловой системы POSIX или в каталоге, указанном переменными окружения TMP и/или TEMP в Windows.

Вы можете явно сконфигурировать пространство для сортировки двумя способами. Первый заключается в установлении каталога с использованием переменной окружения FIREBIRD_TMP (INTERBASE_TMP для версии 1.0.x). Второй способ- сконфигурировать каталоги с использованием параметра конфигурации TempDirectories в firebird.config для версии 1.5 и выше или при добавлении одной или более записей temp directory в файл isc config (POSIX) или ibconfig (Windows) для версии 1.0.x.

Инсталляция по умолчанию не выполняет никакого явного конфигурирования размера памяти сортировки на диске. Подробности и синтаксис таких установок см. в разд. "Параметры для конфигурирования памяти сортировки" главы 36.

Индексирование

Упорядоченные наборы являются дорогостоящими для ресурсов сервера и вообще для производительности. При оценке запроса и определении плана оптимизатор может выбирать между тремя методами доступа к наборам данных (называемым потоками), которые располагаются в указанных таблицах: NATURAL (поиск без какого-либо порядка), INDEX (использование индекса для управления поиском) и MERGE (создание двоичных образов двух потоков и их слияние по принципу один к одному).

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

При методе MERGE (также называемый SORT) каждая строка (а следовательно, и каждая страница) читается только один раз, а чтение выполняется в порядке хранения. В Firebird 1.5, который с большой вероятностью будет использовать оперативную память для сортировки, метод MERGE является наиболее быстрым в большинстве случаев.

Следует еще раз подчеркнуть важность хорошего индексирования для ускорения и улучшения процесса сортировки в упорядоченных запросах. В упорядоченных наборах при правильных условиях метод INDEX С хорошим индексом быстро выдаст первые строки. При этом индекс также может значительно замедлить выборку. Затраты могут быть такими, что весь набор будет выбран гораздо медленнее, чем при использовании альтернативного метода доступа MERGE. В методе MERGE первая строка отыскивается медленнее, но весь набор выбирается быстрее.

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

Предложение ORDER BY