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

前端之家收集整理的这篇文章主要介绍了当从.Net应用程序调用SQL函数与在Management Studio中进行相同调用时,为什么会出现性能差异前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
@H_404_1@我们的测试和开发环境中存在一个问题,其功能在从.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

解决方法

这通常是因为您在SSMS连接中获得了不同的执行计划.通常与参数嗅探问题相关,其中计划生成时具有对于其他参数值次优的特定值.这也解释了为什么重新编译会解决问题.这个帖子似乎有一个很好的解释 Parameter Sniffing (or Spoofing) in SQL Server

猜你在找的MsSQL相关文章