我们遇到了sp的问题。存储过程仅在从应用程序运行时导致超时
我们有一个非常简单的sp，它包含一个声明的表和一些外部连接，最终返回20行和100行之间。
由于查询这个sp在生产和测试环境中都给我们带来了糟糕的表现，我们最近重写了它以提高效率，并且在我们的测试环境中经过了很好的测试。
我们将它发布到生产环境中仅仅是为了发现它仍然非常慢并且导致我们的.NET 2.0应用程序在被调用时超时。
我们什么也没有理解，进入生产数据库的Management Studio并运行sp，它在1秒内执行。
也就是说，当从我们的应用程序运行时，它非常缓慢，并导致超时，从Management Studio运行时非常快速，永远不会超过一秒钟。
任何人都知道SQL Server 2005可以给我们一个提示吗？
确保您的生产数据库具有最新的统计信息并且索引处于良好状态（如果可能，请考虑重新构建涉及的索引）。
你能确定没有发生死锁情况吗？从管理工作室的运行将被隔离，从应用程序这可能是一个更大的交易的一部分。
Thanx for reply guys，似乎正在运行sp_recompile解决了这个问题，至少从昨天下午执行它以来，至少一切都已经运行良好，将继续观察它，看看它是否保持快速。
但是，不要明白，当我改变sp内的内容时没有进行重新编译？
重新编译是一个钝器。这是嗅探
看到这个问题最有可能的参数：Stored Procedure failing on a specific user
我认为你的问题可能是“参数嗅探”。 这是一个当SQL Server的执行环境在编译期间“嗅探”sp的参数值或重新编译生成更快执行计划的过程。但是有时它会得到一个参数组合，这些参数和sp返回的当前数据一起会导致一个非常慢的sp。
这里有几个很好的解释。在Stackoverflow上搜索。 这是一个很好的方法： http://omnibuzz-sql.blogspot.com/2006/11/parameter-sniffing-stored-procedures.html
一个可能的解决方案是在sp中创建局部变量并将传入参数值设置给它们。然后只使用sp中的局部变量。
CREATE PROCEDURE [dbo].spTest
@FromDate as DATETIME
AS
BEGIN
DECLARE @FromDate_local as DATETIME
SET @FromDate_local = '2009-01-01'
SET @FromDate_local = @FromDate
...
SELECT * FROM TestTbl WHERE FromDate >= @FromDate_local
END
当你说你在管理工作室中测试SP时，你是使用EXEC调用SP并提供一些参数，还是只使用SP内部的查询体？ – AnthonyWJones 2009-01-22 10:22:01
您是否使用应用程序用于连接的同一用户在SSMS中进行了测试？ – devio 2009-01-22 10:29:30