Массовый сбор может обеспечить значительный прирост производительности. Однако есть пара причин.
Прежде всего, есть разница в значении% notfound.
На стандартном курсоре% notfound означает, что все строки уже выбраны, и их больше нет. При массовом сборе этих изменений в 'было недостаточно строк, чтобы достичь указанного ПРЕДЕЛА (если присутствует).
Это НЕ означает, что ни одна строка не была выбрана, только указанное ограничение не было достигнуто Например, если ваш лимит равен 100, а извлечение получено только 50, то% notfound вернет True. Это где ссылка руководство терпит неудачу.
Второе - это то, что происходит без предложения limit: все строки из курсора возвращаются в общую память (PGA?). Так в чем же проблема?
Если там 100 строк или 1000, то, скорее всего, вы k, но предположим, что есть 100000 или 1M строк, они все еще загружены в память. Наконец (по крайней мере, на данный момент), когда используется предельное предложение, тогда весь процесс Fetch + должен быть сам заключен в цикл, или вы обрабатываете только первую выборку - то есть только указанное предельное количество строк - независимо от того, сколько на самом деле существует. Еще один момент, когда ссылка на руководство не удается.
Следующий скелет соответствует вышеуказанному.
declare
max_bulk_rows constant integer := 1000; -- define the max number of rows for each fetch ...
cursor c_bulk is(
Select ... ;
type bulk_row_t is table of c_bulk%rowtype;
bulk_row bulk_row_t;
Begin
open c_bulk;
loop
fetch c_bulk -- fill buffer
bulk collect into bulk_row
limit max_bulk_row;
for i in bulk_row.first .. bulk_row.last -- process each row in buffer
loop
"process individual row here"
end loop;
foreach ... -- bulk output of rows here is needed.
exit when bulk_row.count < max_bulk_row; -- exit process loop if all rows processed
end loop ; -- loop back and fetch next buffer if needed
close c_bulk;
...
end;