Managment Studio和TableAdapter之间存储过程的执行时间差异很大

如何通过Management Studio在10秒内运行存储的程序，但是通过TableAdapter为同一输入需要15分钟？这是可重复的，这意味着我已经在每个环境中至少运行了三次，Management Studio的速度始终快了近100倍。Managment Studio和TableAdapter之间存储过程的执行时间差异很大

我使用.NET 2.0和SQL Server 2000

在SQL Server Management，我在执行这样的：

EXEC [dbo].[uspMovesReportByRouteStep] 
    @RouteStep = 12000, 
    @RangeBegin = N'12/28/08', 
    @RangeEnd = N'1/18/9'

在TableAdapter的，我使用的是StoredProcedureCommandType和dbo.uspMovesReportByRouteStep为CommandText。我从ASP.NET页面调用表格适配器，但如果我也尝试在本地“预览数据”，则会在30秒内超时。

提供存储过程是不现实的，因为它存在超过100行的长度，并且依赖于相同数据库和其他数据库上的许多其他UDF和视图。

所有其他存储过程似乎使用任一方法在大约相同的时间运行。这怎么可能？

来源

2009-01-16 recursive

这很可能是由于'参数嗅探'和缓存的查询计划不适合您调用的参数的特定值。这是如何发生的？那么，你第一次用一组值来调用一个SP，一个查询计划将被生成，参数化和缓存。如果使用另一组参数值再次调用SP，该参数值会导致不同的查询计划，但它使用缓存的查询计划，那么性能可能会受到影响。

这通常是因为统计数据过期。您可以通过将预计执行计划与实际执行计划进行比较来确定是否属于这种情况;如果不同，那么统计数据很可能会过时。

我会先尝试重建数据库的索引，或者至少统计数据已更新（询问您的DBA）。重建索引的一种方式（应在SQL Server上的所有版本）：

exec sp_msforeachtable "dbcc dbreindex ('?')"

如果它仍然是一个问题，请尝试暂时将声明WITH RECOMPILE存储过程的定义。如果问题消失，那么看看使用OPTIMIZE FOR，在this博客文章中描述。

来源

2009-01-17 00:04:38

有趣的是，我们这里并没有真正的DBA。不知何故，数据库在没有任何干预的情况下继续进行卡车运输，并且已有多年。但是我有权在服务器上做很多事情，所以也许我会开始嘲笑这个东西。感谢指针。 – recursive 2009-01-17 00:18:57

Managment Studio和TableAdapter之间存储过程的执行时间差异很大

回答

相关问题