Question

我正在使用Dapper从Web应用程序运行存储过程。我首先从SSMS运行了相同的存储过程，以确保一切正常。它从SSMS运行了1-5秒。

然后，我将脚本复制/粘贴到应用程序中，以通过Dapper运行。当我运行我的应用程序并一步调试代码时，该存储过程运行了2分钟以上，并超时。完全相同的代码。是什么原因导致差异？

这是我从SSMS运行的代码：

DECLARE @RC int
DECLARE @ownerId varchar(50)
DECLARE @type varchar(50)
DECLARE @dateFrom datetime
DECLARE @dateTo datetime
DECLARE @offset int
DECLARE @perPage int

SET @ownerId = '990042064' 
SET @type = 'voice' 
SET @dateFrom = '2018-05-16 00:00:00.000'  --'YYYY-MM-DD hh:mm:ss[.nnn]' 
SET @dateTo = '2018-08-14 23:59:59.000'  --'YYYY-MM-DD hh:mm:ss[.nnn]' 
SET @offset = 0 
SET @perPage = 50

EXECUTE @RC = dbo.IndexSearch @ownerId
                             ,@type
                             ,@dateFrom
                             ,@dateTo
                             ,@offset
                             ,@perPage
GO

这是从我的应用程序运行的代码：

using (IDbConnection db = new SqlConnection(ConnectionStringHelper.ConnectionString))
{
    dbRecs = db.Query<IndexRec>(@"
    DECLARE @RC int
    DECLARE @ownerId varchar(50)
    DECLARE @type varchar(50)
    DECLARE @dateFrom datetime
    DECLARE @dateTo datetime
    DECLARE @offset int
    DECLARE @perPage int

    SET @ownerId = '990042064'
    SET @type = 'voice'
    SET @dateFrom = '2018-05-16 00:00:00.000'--'YYYY-MM-DD hh:mm:ss[.nnn]'
    SET @dateTo = '2018-08-14 23:59:59.000'--'YYYY-MM-DD hh:mm:ss[.nnn]'
    SET @offset = 0
    SET @perPage = 50

    EXECUTE @RC = dbo.IndexSearch @ownerId
                                 , @type
                                 , @dateFrom
                                 , @dateTo
                                 , @offset
                                 , @perPage
    ", commandTimeout: 120);
}

我什至尝试在几台不同的计算机上运行SSMS，但我总是在1-5秒内得到它。而且我在应用程序中多次运行了相同的查询，并且总是超时。

脚本本身中是否有任何东西导致执行计划不同？我还使用了来自SSMS和我的应用的相同登录名。

Answer 1

如Lukasz所述，它可能是参数嗅探，也可能是其他。

博客已经有很多问题可以理解为什么！

http://www.sommarskog.se/query-plan-mysteries.html

或者您可以尝试https://stackoverflow.com/a/12483089/1481690

看看ASP.Net应用程序的sys.dm_exec_sessions和用于您的SSMS会话。我会猜测，至少有一个 SET设置不同。这可以有助于制定不同的计划（最终这归因于参数嗅探）和应用通常会变得更糟。

Answer 2

尝试此页上的建议：我认为参数嗅探可能会引起麻烦，但是ARITHABORT解决方案可能会起作用。在任何情况下，请尝试使用optiins（重新编译）。 SQL Query slow in .NET application but instantaneous in SQL Server Management Studio

Answer 3

该解决方案应基于将存储过程参数分配给局部变量（请看一下参数嗅探）。下面提供了指向您可能会觉得有用的文章的链接： https://www.tangrainc.com/blog/2007/08/parameter-sniffing/

为什么存储过程从代码运行慢，而从SSMS运行快？

3 个答案: