当从.Net应用程序调用SQL函数与在Management Studio中进行相同调用时,为什么会出现性能差异

Question

我们的测试和开发环境中存在一个问题,其功能在从.Net应用程序调用时运行得非常慢.当我们直接从管理工作室调用此函数时,它工作正常.

以下是它们分析时的差异:来自应用程序:
CPU:906
读取:61853
写入:0
持续时间:926

从SSMS:
CPU:15
阅读:11243写道
:0
持续时间:31

现在我们已经确定,当我们重新编译该函数时,性能将返回到我们期望的结果,并且从应用程序运行时的性能配置文件与从SSMS运行时获得的性能配置文件相匹配.它会以随机间隔的形式再次开始减速.

我们还没有在生产中看到这一点,但它们可能部分是因为每周都会重新编译所有内容.

那么什么可能导致这种行为？

编辑 -
我们终于能够解决这个问题并重组变量来处理参数嗅探似乎已经完成了诀窍......我们在这里做了一个片段:感谢您的帮助.

        -- 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

我对存储过程有类似的问题,对我来说它原来是'参数嗅探'.谷歌,并看看它是否解决了你的问题,对我来说,一旦我修复它,它是戏剧性的加速.

在我的例子中,我通过为传入的每个参数声明一个局部变量来修复它,然后将局部变量分配给该参数值,并且其余的proc使用局部变量进行处理......无论出于何种原因,这打败了参数嗅探.

Answer 2

这通常是因为您在 SSMS 连接中获得了不同的执行计划。通常与参数嗅探问题相关，其中当使用特定值生成计划时，该特定值对于参数的其他值来说是次优的。这也解释了为什么重新编译可以解决该问题。该线程似乎对 SQL Server 中的参数嗅探（或欺骗）有很好的解释