при использовании курсора для взаимодействия с набором результатов все результаты будут загружены в память

Question

Если набор результатов огромен, будет ли эффективным использование памяти курсором?

Answer 1

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

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

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

Если я пытаюсь оптимизировать свой PL / SQL для производительности и использования памяти, мне нравится использовать BULK COLLECT с LIMIT в цикле, например ::10000 *

DECLARE
  BATCHSIZE CONSTANT INTEGER := 1000;
  CURSOR mycursor IS SELECT ...;
  TYPE mytabletype IS TABLE OF mycursor%ROWTYPE INDEX BY PLS_INTEGER;
  myarray mytabletype;
BEGIN
  OPEN mycursor;
  LOOP
    FETCH mycursor INTO myarray LIMIT BATCHSIZE;
    EXIT WHEN myarray.COUNT = 0;
    FOR i IN 1..myarray.COUNT LOOP
      -- do the processing on myarray(i)
    END LOOP;
  END LOOP;
  CLOSE mycursor;
END;

Приведенный выше код упрощает настройку размера пакета для максимизации пропускной способности без использования слишком большого объема памяти за сеанс.

Answer 2

Как правило, вы должны пытаться использовать «заданные» операторы SQL, которые работают с набором записей на основе запроса, а не использовать курсор и циклически перебирать данные. Большинство администраторов баз данных считают, что курсоры - это зло, потому что они занимают слишком много памяти, включают в себя блокировки, которые препятствуют выполнению других задач, а также гораздо более неэффективны (иногда на несколько порядков), чем хорошо продуманный оператор SQL.