Question

如何通过Management Studio在10秒内运行存储过程，但是通过TableAdapter为相同的输入花费15分钟？它是可重复的，这意味着我在每个环境中至少运行了三次，而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 CommandType和dbo.uspMovesReportByRouteStep作为CommandText。我正在从ASP.NET页面调用表适配器，但如果我尝试在本地“预览数据”，它会在30秒内超时。

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

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

Answer 1

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

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

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

exec sp_msforeachtable "dbcc dbreindex ('?')"

如果仍然存在问题，请尝试将语句WITH RECOMPILE临时添加到存储过程定义中。如果问题消失，请查看this博文中所述的OPTIMIZE FOR。