Почему существуют различия в производительности, когда функция SQL вызывается из приложения .Net по сравнению с аналогичным вызовом в Management Studio?

Question

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

Вот различия, когда они профилированы: Из приложения:
Процессор: 906
Считывает: 61853
Пишет: 0
Продолжительность: 926

из SSMS:
ЦП: 15
Чтения: 11243
Запись: 0
Продолжительность: 31

Теперь мы определили, что при перекомпиляции функции производительностьвозвращает к тому, что мы ожидаем, и профиль производительности при запуске из приложения совпадает с тем, что мы получаем при запуске из SSMS.Он начнет снова замедляться с тем, что кажется случайным интервалом.

Мы не видели этого в prod, но они могут быть частично, потому что все перекомпилируется там еженедельно.

Так чтоможет вызвать такое поведение?

Edit -
Мы наконец-то смогли справиться с этим, и реструктуризация varables, чтобы справиться с анализом параметров, похоже, сделала свое дело ... фрагмент того, что мы сделали здесьСпасибо за вашу помощь.

        -- create set of local variables for input parameters - this is to help performance - vis a vis "parameter sniffing"
    declare @dtDate_Local                  datetime
           ,@vcPriceType_Local             varchar(10)
           ,@iTradingStrategyID_Local      int
           ,@iAccountID_Local              int
           ,@vcSymbol_Local                varchar(10)
           ,@vcTradeSymbol_Local           varchar(10)
           ,@iDerivativeSymbolID_Local     int
           ,@bExcludeZeroPriceTrades_Local bit

   declare @dtMaxAggregatedDate     smalldatetime
          ,@iSymbolID               int
          ,@iDerivativePriceTypeID  int

   select @dtDate_Local                  = @dtDate
          ,@vcPriceType_Local             = @vcPriceType
          ,@iTradingStrategyID_Local      = @iTradingStrategyID
          ,@iAccountID_Local              = @iAccountID
          ,@vcSymbol_Local                = @vcSymbol
          ,@vcTradeSymbol_Local           = @vcTradeSymbol
          ,@iDerivativeSymbolID_Local     = @iDerivativeSymbolID
          ,@bExcludeZeroPriceTrades_Local = @bExcludeZeroPriceTrades

Answer 1

У меня была похожая проблема с хранимыми процедурами, и для меня это оказалось «анализом параметров». Поищи это и посмотри, решит ли это твою проблему, для меня это было резкое ускорение, как только я это исправил.

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

Answer 2

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

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

Это обновит всю статистику и обновит представления и сохраненные процессы (но будьте осторожны при запуске наПроизводство машины):

EXEC sp_updatestats

EXEC sp_refreshview 

EXEC sp_msForEachTable 'EXEC sp_recompile ''?'''

Answer 3

Обычно это происходит потому, что вы получаете другой план выполнения в вашем соединении SSMS. Часто связано с проблемами отслеживания параметров, когда план генерируется с определенным значением, которое является субоптимальным для других значений параметров. Это также объясняет, почему перекомпиляция решит проблему. Похоже, что этот поток имеет хорошее объяснение Анализ параметров (или спуфинг) в SQL Server