SP, занимающий 15 минут, но тот же запрос, когда выполняемые возвраты заканчивается за 1-2 минуты

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

exec sp_recompile 'YourSproc'

Затем запустите sproc, стараясь использовать разумные параметры.

Также сравните фактические планы выполнения между двумя методами выполнения запрос.

Возможно, стоит пересчитать любую статистику.

Я бы также изучил анализ параметров. Возможно, процессу нужно немного по-другому обрабатывать параметры.

Обычно я начинаю устранять подобные проблемы, используя "print getdate () + '- step'". Это помогает мне сузить круг вопросов, на которые уходит больше всего времени. Вы можете сравнить с того места, где вы его запускаете, из анализатора запросов и сузить круг проблем.

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

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

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

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

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

Что касается того, почему SP занимает больше времени, чем запрос - трудно сказать. При использовании каждого подхода одинаковая нагрузка на систему? Если вы запустите сам запрос при небольшой нагрузке, это будет лучше, чем при запуске SP при большой нагрузке.

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

DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS

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

Я бы предположил, что проблема связана с типом временной таблицы (префикс #). Эта временная таблица содержит данные для этого сеанса базы данных. Когда вы запускаете его через приложение, временная таблица удаляется и создается заново.
Вы можете обнаружить, что при работе в SSMS он сохраняет данные сеанса и обновляет таблицу вместо ее создания. Надеюсь, что это поможет :)

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

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