小编典典

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

sql

在测试和开发环境中,我们遇到了一个问题,该函数有时会从.Net应用程序调用时运行得非常慢。当我们直接从Management
Studio调用此功能时,它可以正常工作。

剖析它们时的区别是:从应用程序:
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

阅读 142

收藏
2021-03-23

共1个答案

小编典典

这通常是因为您在SSMS连接中获得了不同的执行计划。通常与参数嗅探问题相关,在该问题中,何时生成计划时使用的特定值对于参数的其他值而言是次最佳的。这也解释了为什么重新编译可以解决该问题。此线程似乎对SQLServer中的参数嗅探(或欺骗)有很好的解释。

2021-03-23