2

存储过程如何通过 Management Studio 在 10 秒内运行，但通过 TableAdapter 需要 15 分钟才能获得相同的输入？它是可重复的，这意味着我在每个环境中至少运行了 3 次，而 Management Studio 始终快 100 倍左右。

我正在使用 .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 中，我使用StoredProcedure CommandTypeanddbo.uspMovesReportByRouteStep作为CommandText. 我正在从 ASP.NET 页面调用表适配器，尽管如果我也尝试在本地“预览数据”它会在 30 秒内超时。

提供存储过程是不切实际的，因为它有超过 100 行长，并且依赖于许多其他 UDF 以及同一数据库和其他数据库上的视图。

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

4

1 回答 1

5

这很可能是由于“参数嗅探”和缓存的查询计划不适合您调用它的参数的特定值。这是怎么发生的？好吧，当您第一次使用一组值调用 SP 时，将生成、参数化和缓存查询计划。如果使用另一组可能导致不同查询计划的参数值再次调用 SP，但它使用缓存的查询计划，则性能可能会受到影响。

这通常是因为统计数据已过时。您可以通过将估计执行计划与实际执行计划进行比较来确定是否是这种情况；如果不同，则统计数据很可能已过时。

我会首先尝试重建数据库的索引，或者至少更新它的统计信息（询问您的 DBA）。重建索引的一种方法（应该适用于 SQL Server 上的所有版本）：

exec sp_msforeachtable "dbcc dbreindex ('?')"

如果仍然存在问题，请尝试暂时将语句添加WITH RECOMPILE到存储过程定义中。如果问题消失了，那么看看 using OPTIMIZE FOR，在这篇博文中描述。

于 2009-01-17T00:04:38.150 回答