Который быстрее в SQL, Цикле с условием продолжения, Рекурсивном Сохраненном proc или Курсоре?

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

Если вы хотите повысить производительность, то вам нужно обратить внимание на операции на основе SET. Цикл While и курсор - это, по сути, одно и то же. SQL работает в SETах, это не процедурный язык, используйте его так, как он предназначен для использования

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

Правда о курсорах

I ' Предположим, вы используете SQL Server.

Прежде всего, как кто-то сказал в инструкциях, рекурсивные хранимые процессы, хотя и возможны, не являются хорошей идеей для SQL Server из-за размера стека. Итак, любая глубоко рекурсивная логика сломается. Однако, если у вас есть в лучшем случае 2-3 уровня вложенности, вы можете попробовать использовать рекурсию или использовать CTE , который также является немного рекурсивным (SQL Server 2005 и выше). Как только вам удастся осмыслить CTE, это станет чрезвычайно полезной техникой. Я не измерял, но у меня никогда не было проблем с производительностью в тех немногих местах, где я использовал CTE.

Курсоры, с другой стороны, сильно влияют на производительность, поэтому я ( и половина Интернета ) рекомендовал бы не использовать их в коде, который часто вызывается. Но поскольку курсоры - это скорее классическая структура программирования, похожая на foreach в C #, некоторым людям легче смотреть, понимать и поддерживать код SQL, который использует курсоры для манипулирования данными, по некоторым запутанным множественным внутренним элементам. -выбрать чудовищность SQL, поэтому не самая плохая идея использовать их в коде, который будет вызываться время от времени.

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

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

1. Используя подход, основанный на наборах (внутренние выборки, объединения, объединения и т. Д.)
2. Использование CTE (очистить и управляемый для опытного пользователя, немного сомнительный для новичка)
3. Использование операторов потока управления (if, while ...)
4. Использование курсоров (процедурный код, легко следовать)

в указанном порядке.

Если код используется гораздо реже, я, вероятно, переставлю 3 и 4 перед 1 и 2, но, опять же, только для сложных сценариев, которые используют много таблиц и много отношений. Конечно, YMMV, поэтому я бы протестировал любую процедуру, которую я выполняю, в реальном сценарии, чтобы на самом деле измерить производительность, потому что мы можем говорить, пока не посинем, об этом быстро, а это медленно, но до тех пор, пока вы получаете реальные измерения, невозможно определить, улучшают или ухудшают ситуацию изменения.

И не забывайте, что скорость кода зависит от скорости ваших данных. Хорошая индексация ничем не заменит.

Вы еще не знаете, но хотите прочитать эту книгу.

http://www.amazon.com/Refactoring-SQL-Applications-Stephane-Faroult/dp/0596514972

D) Ничего из вышеперечисленного.

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

Лучше всего протестировать все возможные методы, которые у вас есть, и посмотреть, какой из них действительно самый быстрый.

Взгляните на Курсоры и как их избежать , где вы узнаете, как заменить курсоры операциями на основе SET