14

我正在尝试从我的 C# Web 应用程序中运行插入查询。当我从 SQL Server Management Studio 运行查询时，插入查询大约需要五分钟才能完成。从应用程序运行时，它会在三十分钟后超时（是的分钟，而不是秒）。

我已经从 VS 调试器中获取了实际的 SQL 语句并从 Mgmt Studio 运行它，它工作正常。

所有这些都是在我的开发环境中运行的，而不是生产环境。查询正在进行时没有其他 SQL Server 活动。我正在使用 SQL Server 2008 R2 进行开发。MS VS 2010 Express，Asp.Net 4.0。SQL Server 管理工作室 10。

有一个类似的问题从未得到回答：SQL server timeout 2000 from C# .NET

以下是 SET 选项：dbcc useroptions

Option                  MgtStudio      Application
----------------------- -------------- --------------
textsize                2147483647     -1
language                us_english     us_english
dateformat              mdy            mdy
datefirst               7              7
lock_timeout            -1             -1
quoted_identifier       SET            SET
arithabort              SET            NOT SET
ansi_null_dflt_on       SET            SET
ansi_warnings           SET            SET
ansi_padding            SET            SET
ansi_nulls              SET            SET
concat_null_yields_null SET            SET
isolation level         read committed read committed

只有 textsize 和 arithabort 不同。

任何想法为什么查询执行时间存在如此差异以及我可以做些什么来缩小这种差异？

我不确定包含查询会有多大用处，特别是因为包含模式太多了。无论如何，这里是：

INSERT INTO GeocacherPoints
            (CacherID,
             RegionID,
             Board,
             Control,
             Points)
SELECT z.CacherID,
       z.RegionID,
       z.Board,
       21,
       z.Points
FROM   (SELECT CacherID,
               gp.RegionID,
               Board=gp.Board + 10,
               ( CASE
                   WHEN (SELECT COUNT(*)
                         FROM   Geocache g
                                JOIN GeocacheRegions r
                                  ON ( r.CacheID = g.ID )
                         WHERE  r.RegionID = gp.RegionID
                                AND g.FinderPoints >= 5) < 20 THEN NULL
                   ELSE (SELECT SUM(y.FinderPoints) / 20
                         FROM   (SELECT x.FinderPoints,
                                        ROW_NUMBER() OVER (ORDER BY x.FinderPoints DESC, x.ID) AS Row
                                 FROM   (SELECT g.FinderPoints,
                                                g.ID
                                         FROM   Geocache g
                                                JOIN Log l
                                                  ON ( l.CacheID = g.ID )
                                                JOIN Geocacher c
                                                  ON ( c.ID = l.CacherID )
                                                JOIN GeocacheRegions r
                                                  ON ( r.CacheID = g.ID )
                                         WHERE  YEAR(l.LogDate) = @Year
                                                AND g.FinderPoints >= 5
                                                AND c.ID = gp.CacherID
                                                AND r.RegionID = gp.RegionID) x) y
                         WHERE  y.Row <= 20)
                 END ) Points
        FROM   GeocacherPoints gp
               JOIN Region r
                 ON r.RegionID = gp.RegionID
        WHERE  gp.Control = 21
               AND r.RegionType IN ( 'All', 'State' )
               AND gp.Board = @Board - 10) z
WHERE  z.Points IS NOT NULL
       AND z.Points >= 1
4

3 回答 3

7

ARITHABORT常被误诊为病因。

事实上，自从版本 2005ANSI_WARNINGS开启（因为它在您的两个连接中）ARITHABORT之后，无论如何都是隐式开启的，并且此设置没有实际效果。

但是，它确实有副作用。为了考虑到ANSI_WARNINGS关闭的情况，设置ARITHABORT被用作计划缓存键之一，这意味着具有不同设置的会话不能共享彼此的计划。

当您在 SSMS 中运行查询时，无法重用为您的应用程序缓存的执行计划，除非它们都具有相同的计划缓存键，因此它会编译一个新计划，“嗅探”当前正在测试的参数值。您的应用程序的计划可能是针对不同的参数值编译的。这个问题被称为“参数嗅探”。

您可以检索两个执行计划并将其与类似的内容进行比较

SELECT usecounts, cacheobjtype, objtype, text, query_plan, value as set_options
FROM sys.dm_exec_cached_plans 
CROSS APPLY sys.dm_exec_sql_text(plan_handle) 
CROSS APPLY sys.dm_exec_query_plan(plan_handle) 
cross APPLY sys.dm_exec_plan_attributes(plan_handle) AS epa
where text like '%INSERT INTO GeocacherPoints (CacherID,RegionID,Board,Control,Points)%' 
and attribute='set_options' and text not like '%this query%'

XML 中的参数部分告诉您参数的编译时间值。

看到应用程序慢，SSMS 快？了解更多性能奥秘。

执行计划

您提供了估计的执行计划而不是实际的执行计划，但可以看出只有第一个查询计划是参数化的，并且它是针对以下值编译的。

        <ParameterList>
          <ColumnReference Column="@Dec31" ParameterCompiledValue="'2013-12-31'" />
          <ColumnReference Column="@Jan1" ParameterCompiledValue="'2013-01-01'" />
          <ColumnReference Column="@Board" ParameterCompiledValue="(71)" />
        </ParameterList>

第二个执行计划使用变量而不是参数。这极大地改变了事情。

DECLARE @Board INT
DECLARE @Jan1 DATE
DECLARE @Dec31 DATE

SET @Board=71
SET @Jan1='January 1, 2013'
SET @Dec31='December 31, 2013'

INSERT INTO GeocacherPoints

SQL Server 不会嗅探变量的特定值，而是生成类似于使用OPTIMIZE FOR UNKNOWN提示的通用计划。该计划中的估计行数远高于第一个计划中的行数。

你没有说明哪个是快计划，哪个是慢计划。如果使用变量的速度更快，那么您可能需要更新统计信息，您很可能会遇到此处描述的问题统计、行估计和升序日期列，如果使用参数的速度更快，那么您将能够实现变量嗅探并获得它通过使用OPTION (RECOMPILE)提示来考虑实际变量值。

于 2013-01-03T22:28:26.243 回答
4

如果您使用 SqlCommand 并且没有为CommandTimeout指定值，它将在 30 秒后自动超时。

于 2013-01-03T19:19:14.590 回答
-1

这个问题似乎会定期出现，这个链接位于列表顶部： Query timeouts from web app but runs fine from management studio。 ARITHABORT显然是罪魁祸首。

于 2013-01-03T20:34:51.460 回答