在测试和开发环境中,我们遇到了一个问题,该函数有时会从.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
这通常是因为您在SSMS连接中获得了不同的执行计划。通常与参数嗅探问题相关,在该问题中,何时生成计划时使用的特定值对于参数的其他值而言是次最佳的。这也解释了为什么重新编译可以解决该问题。此线程似乎对SQLServer中的参数嗅探(或欺骗)有很好的解释。