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

Question

我们在测试和开发环境中遇到了一个问题，当从 .Net 应用程序调用时，该函数运行速度非常慢。当我们直接从管理工作室调用这个函数时，它工作正常。

以下是对它们进行分析时的差异:
从应用程序:
中央处理器:906
阅读:61853
写入:0
持续时间:926

来自 SSMS:
中央处理器:15
阅读:11243
写入:0
持续时间:31

现在我们已经确定，当我们重新编译函数时，性能会恢复到我们预期的那样，并且从应用程序运行时的性能配置文件与我们从 SSMS 运行它时获得的性能配置文件相匹配。它将以随机间隔再次开始减速。

我们还没有在 prod 中看到过这种情况，但它们可能部分是因为每周都会在那里重新编译所有内容。

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

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

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

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