Я знаю, что курсоры (неявные или явные) могут быть созданы для операторов SELECT.
Но курсоры (скажем, неявные) также создаются для операций INSERT, UPDATE и DELETE. Если они делают то, что там цель.
Чтобы внести ясность в вопрос: оператор SELECT может привести к миллиону записей, и создание нечувствительного (фактические данные копируются) курсора может быть полезно для возврата результатов клиенту, когда клиент прокручивает вперед или назад и можно избежать отправки всех данных в одном сетевом запросе. И любые другие преимущества, о которых стоит упомянуть, приветствуются.
Но с операциями записи (INSERT, UPDATE и DELETE) требуется курсор, не будет ли это накладным расходом ресурсов, даже если рассматривается параллелизм .? Если операция должна потерпеть неудачу, она просто потерпит неудачу раньше. Или дело в том, что для изоляции транзакций они необходимы. Таким образом, атомарность и согласованность гарантируются созданием курсора. (параллелизм может быть обработан с помощью комбинации других механизмов, таких как 2PL или MVCC и т. д., но на данный момент я больше сосредоточен на роли курсоров в транзакции)
Таким образом, кажется, что транзакции также необходимо учитывать, приводит ли каждая транзакция к созданию курсора (неявно). Или, учитывая, что существуют другие механизмы для обработки транзакций (с параллелизмом и без), курсор вообще не имеет права голоса или просто играет ограниченную роль при работе с транзакцией.
