对于相同的输入，存储过程如何通过 Management Studio 在 10 秒内运行，但通过 TableAdapter 需要 15 分钟？它是可重复的，这意味着我在每个环境中至少运行了 3 次，并且 Management Studio 的速度始终快了 100 倍左右。
我正在使用 .net 2.0 和 SQL Server 2000
在 SQL Server 管理中，我像这样执行它：
EXEC [dbo].[uspMovesReportByRouteStep]
@RouteStep = 12000,
@RangeBegin = N'12/28/08',
@RangeEnd = N'1/18/9'
在 TableAdapter 中，我使用的是StoredProcedure CommandType and dbo.uspMovesReportByRouteStep为了CommandText。我从 ASP.NET 页面调用表适配器，但如果我也尝试在本地“预览数据”，它会在 30 秒内超时。
提供存储过程是不切实际的，因为它的长度超过 100 行，并且依赖于同一数据库和其他数据库上的许多其他 UDF 和视图。
使用任一方法，所有其他存储过程似乎都在大约相同的时间运行。这怎么可能？
这很可能是由于“参数嗅探”和缓存的查询计划不适合您调用它的参数的特定值。这是怎么发生的？那么，第一次使用一组值调用 SP 时，将生成、参数化并缓存查询计划。如果使用另一组参数值再次调用 SP，这会导致不同的查询计划，但它使用缓存的查询计划，那么性能可能会受到影响。
这通常是因为统计数据已经过时。您可以通过将估计执行计划与实际执行计划进行比较来确定是否属于这种情况；如果不同，那么统计数据很可能已经过时。
我首先尝试重建数据库的索引，或者至少更新统计信息（询问您的 DBA）。重建索引的一种方法（应该适用于 SQL Server 上的所有版本）：
exec sp_msforeachtable "dbcc dbreindex ('?')"
如果还是有问题，尝试临时添加语句WITH RECOMPILE到存储过程定义。如果问题消失，请查看使用OPTIMIZE FOR，描述于this博客文章。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
