Почему люди так ненавидят курсоры SQL?

«Накладные расходы» на курсоры - это просто часть API. Курсоры - это то, как части СУБД работают под капотом. Часто CREATE TABLE и INSERT имеют SELECT операторы, и реализация является очевидной реализацией внутреннего курсора.

Использование высокоуровневых «операторов на основе наборов» объединяет результаты курсора в единый набор результатов, что означает меньшее количество операций API вперед и назад.

Курсоры предшествуют современным языкам, которые предоставляют первоклассные коллекции. В старых версиях C, COBOL, Fortran и т. Д. Приходилось обрабатывать строки по одной, потому что не существовало понятия «коллекции», которое можно было бы широко использовать. Java, C #, Python и т. Д. Имеют первоклассные структуры списков для хранения наборов результатов.

Медленная проблема

В некоторых кругах реляционные соединения являются загадкой, и люди будут писать вложенные курсоры, а не простое соединение. Я видел поистине эпические операции вложенного цикла, записанные в виде множества курсоров. Как победить оптимизацию РСУБД. И работает очень медленно.

Простое переписывание SQL для замены вложенных циклов курсора объединениями, а единственный плоский цикл курсора может заставить программы работать в 100 раз быстрее. [Они думали, что я бог оптимизации. Все, что я сделал, это заменил вложенные циклы на соединения. Курсоры все еще используются.]

Эта путаница часто приводит к обвинению в использовании курсоров. Однако проблема не в курсоре, а в неправильном использовании курсора.

Проблема размера

Для действительно эпичных наборов результатов (например, выгрузки таблицы в файл) курсоры необходимы. Операции на основе наборов не могут материализовать действительно большие наборы результатов в виде единой коллекции в памяти.

Альтернативы

Я стараюсь как можно больше использовать слой ORM. Но это преследует две цели. Во-первых, курсоры управляются компонентом ORM. Во-вторых, SQL отделяется от приложения в файле конфигурации. Дело не в том, что курсоры плохие. Дело в том, что кодирование всех этих операций открытия, закрытия и выборки не является дополнительным программированием.

Курсоры заставляют людей чрезмерно применять процедурный образ мышления к среде, основанной на наборах.

И они МЕДЛЕННЫЕ !!!

Из SQLTeam:

Обратите внимание, что курсоры - это САМЫЙ МЕДЛЕННЫЙ способ доступа к данным внутри SQL Server. Его следует использовать только тогда, когда вам действительно нужно получить доступ к одной строке за раз. Единственная причина, по которой я могу это придумать, - это вызов хранимой процедуры для каждой строки. В статье о производительности курсора я обнаружил, что курсоры более чем в тридцать раз медленнее заданного альтернативы на основе.

Выше есть ответ, в котором говорится, что «курсоры - САМЫЙ МЕДЛЕННЫЙ способ доступа к данным внутри SQL Server ... курсоры более чем в тридцать раз медленнее, чем альтернативы, основанные на наборах».

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

При отсутствии других операций с базой данных операции с наборами всегда выполняются быстрее. В производственных системах это зависит.

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

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

Очевидно, существуют ситуации, когда курсоры - правильный выбор или, по крайней мере, правильный выбор.

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

В Oracle PL / SQL курсоры не приводят к блокировкам таблиц, и можно использовать массовый сбор / массовую выборку.

В Oracle 10 часто используемый неявный курсор

  for x in (select ....) loop
    --do something 
  end loop;

неявно выбирает 100 строк за раз. Также возможен явный массовый сбор / массовая выборка.

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

Другая причина - это распараллеливание. Базе данных проще распараллеливать большие операторы на основе наборов, чем построчный императивный код. По той же причине, почему функциональное программирование становится все более популярным (Haskell, F #, Lisp, C # LINQ, MapReduce ...), функциональное программирование упрощает распараллеливание. Число процессоров на компьютер растет, поэтому распараллеливание становится все более серьезной проблемой.

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

В приведенных выше ответах недостаточно подчеркивается важность блокировки. Я не большой поклонник курсоров, потому что они часто приводят к блокировкам на уровне таблицы.

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

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

Можете ли вы опубликовать этот пример курсора или ссылку на вопрос? Возможно, есть способ лучше, чем рекурсивный CTE.

В дополнение к другим комментариям, курсоры при неправильном использовании (что часто бывает) вызывают ненужные блокировки страниц / строк.

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

Что касается вашего вопроса, хотя, безусловно, существуют ситуации, когда курсор может быть вызван, по моему опыту разработчики решают, что курсор «должен» использоваться ДАЛЬШЕ чаще, чем на самом деле. На мой взгляд, вероятность того, что кто-то ошибется в отношении слишком частого использования курсоров по сравнению с их неиспользованием, когда они должны были, НАМНОГО выше.

в основном 2 блока кода, которые делают то же самое. может быть, это немного странный пример, но он подтверждает суть дела. SQL Server 2005:

SELECT * INTO #temp FROM master..spt_values
DECLARE @startTime DATETIME

BEGIN TRAN 

SELECT @startTime = GETDATE()
UPDATE #temp
SET number = 0
select DATEDIFF(ms, @startTime, GETDATE())

ROLLBACK 

BEGIN TRAN 
DECLARE @name VARCHAR

DECLARE tempCursor CURSOR
    FOR SELECT name FROM #temp

OPEN tempCursor

FETCH NEXT FROM tempCursor 
INTO @name

SELECT @startTime = GETDATE()
WHILE @@FETCH_STATUS = 0
BEGIN

    UPDATE #temp SET number = 0 WHERE NAME = @name
    FETCH NEXT FROM tempCursor 
    INTO @name

END 
select DATEDIFF(ms, @startTime, GETDATE())
CLOSE tempCursor
DEALLOCATE tempCursor

ROLLBACK 
DROP TABLE #temp

одно обновление занимает 156 мс, а курсора - 2016 мс.