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

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中,我正在使用a StoredProcedure CommandType和dbo.uspMovesReportByRouteStepfor CommandText.我正在从ASP.NET页面调用表适配器,但如果我尝试在本地"预览数据",它会在30秒内超时.

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

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

Answer 1

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

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

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

exec sp_msforeachtable "dbcc dbreindex ('?')"

如果仍然存在问题,请尝试将该语句临时添加WITH RECOMPILE到存储过程定义中.如果问题消失,那么请看一下使用OPTIMIZE FOR,在这篇博文中有所描述.