Cobalt747,

я на курсах легко рисую запрос, генерирующий гигабайты в temp из базы employee.fdb (2.6 мб). Точно не помню, но примерно так

select e1.*
from employee e1, employee e2, employee e3, employee e4
order by e1.first_name

на размер файла сортировки влияет а) количество сортируемых записей, б) длина выдаваемой "записи", т.е. длина столбцов в select.
В вышеприведенном случае
42*42*42*42 записей = 3млн, макс. размер записи 135 байт, получаем 400 мб темп (как минимум). Если в запросе написать
select e1.*, e2.*
то получим уже 56 гиг. Развлекаться можно сколько угодно.

Получить аналогичные результаты можно на гораздо меньшей выборке, например, со столбцами Varchar(10000), если кому-то приспичило такое "на всякий случай", а хранится там максимум 100-200 байт. Все равно развернется при сортировке до 10к байт, а там уже умножаем на кол-во записей.

Cobalt747,

order by "оптимизируется индексами" только при определенных и достаточно жестких условиях. Внутри запрос может как угодно оптимизироваться, но если стоит PLAN SORT, то это сортировка в памяти/на диске однозначно.

Я же написал
select *
...
order by ...
то есть внутри запроса может быть что угодно, оно влияет только на количество записей, которое выбирается.

И опять же, штатный, не штатный - не надо писать select * в запросах с plan sort. Все это * полезет в файл сортировки.

kdvselect e1.*, e2.*
то получим уже 56 гиг. Развлекаться можно сколько угодно.
упс, фигню написал (умножил вместо сложения).
Разумеется, тут получится 800мб, ибо 135 байт записи плюс еще 135, и дальше умножить на 3млн записей.
Но если в этом примере будет даже не select e1.* а select один_столбец_varchar(10000) , то при тех же 3млн записей файл сортировки будет уже не менее 31 гиг.

В общем, смотреть, что делает клиент, какой в этот момент выдается запрос, есть ли в его плане plan sort (скорее всего есть, раз есть темп-файл fb_sort_xxx), и какие столбцы при этом выбираются (их макс. размер).