DrNull
Простой пример: Три таблички, две по паре миллионов записей, одна тысяч 10. Основной зажим идет по маленькой, которая является связующей для двух больших - вывод как раз из больших. По "маленькой" не удается подобрать индекс на поле, по которому "зажим" where. Всё. Приехали.
Будут просто дикие сканы и запрос умрет по таймауту.
Другой вариант - отбираем нужные записи из "маленькой" в #таблицу, получаем их ,например, десяток. Эту #таблицу привязываем к "большим". В теории должно быть одинаково по времени. На практике - даже не в разы, на порядки быстрее работает.


Ну и вовсе не обязательно здесь что-то разбивать. Достаточно добиться нужного плана запроса от сервера. Чтобы "маленькая" была первой. Например используя forceplan.

DrNull
По плану запроса он в скан не валится - оптимизатор ПОКАЗЫВАЕТ красивый план. Однако идет огромный i/o у процесса. Все висит и тормозит. Фактически либо идет скан таблицы, либо потуги выпихнуть ненужный индекс и загрузить нужный сейчас.


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

DrNull
Гадать не буду :) Реально - выкидываеешь из соединения половину таблиц в отдельный селект с инсертом в # и привязываешь её ко второму селекту со второй половиной таблиц и все начинает крутится мнооого быстрее.

Это - эффект. Я думаю, того же эффекта можно добиться было бы и без
разбиения на куски.

DrNull
ИМХО практически всегда, когда возвращается больше сотни записей (да, работа такая, это реально нужно) или есть сортировка или группировка.


Вот именно , только если есть сортировки (причем в этом случае не всегда) или группировка или DISTINCT или UNION. А количество записей здесь ни при чем - я могу вытаскивать миллионы записей без рабочих таблиц (кстати иногда приходится именно специально так делать, чтобы выгрузка данных была быстрее).

DrNull
Опять же Fetch надо как то делать... Не держать же все в полуподвешенном состоянии...


А для этого промежуточная таблица не нужна, для этого есть буфера ввода-вывода и асинхронный сетевой IO.

DrNull
ЗЫ Все вышесказанное справедливо для больших баз (сечас реально в базе свыше 1,5К таблиц сумманым объемом под 100GB )


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