我从一个网站查询，需要15-30秒，而同一查询在0.5秒内从SQL Server Management Studio运行。我无法使用SQL事件探查器看到任何锁定问题，也无法从SSMS手动重现延迟。一个星期前，我分离并重新连接数据库，似乎奇迹般地解决了这个问题。今天当问题又重新出现时，我只是试图重建索引。这也解决了这个问题。但是，我认为这不一定是索引问题，因为根据我的知识，索引不会在简单的分离/附加上自动重建。
知道什么可能导致延迟吗？我的第一个想法是，可能有一些参数嗅探正在调用的存储过程（所述存储过程运行CTE，如果这很重要）导致错误的查询计划，这将解释问题的间歇性。由于分离/重新附加和索引重建在理论上应该使缓存的查询计划无效，这是有道理的，但我不确定如何验证这一点。另外，为什么不能通过SSMS手动运行相同的查询（直接从具有相同参数的SQL事件探查器复制）显示相同的延迟？
有什么想法吗？
答案 0 :(得分：7)
我知道我很晚才讨论这个话题，但是我想发布一个我遇到类似问题的解决方案。简而言之，在我的程序开始时添加SET ARITHABORT ON命令使网站查询性能与SQL Server工具的性能一致。当您从QA或SSMS运行查询时，通常会在连接上设置此选项（您可以更改该选项，但这是默认选项）。
就我而言，我有大约15种不同的存储过程，它们在相当大的数据集（10到100万行）中进行数学聚合（SUM，COUNT，AVG，STDEV） - 添加了SET ARITHABORT ON选项它们全部从3-5秒运行到20-30ms。
所以，希望能帮助其他人。
答案 1 :(得分：6)
如果缓存了错误的计划，那么如果你使用相同的参数运行相同的查询，那么也应该从SSMS使用相同的错误计划。
寻找根本原因无法找到更好的解决方案。试图窥视和戳各种设置，希望它能解决问题永远不会给你实际修复的信心。此外，下次系统可能会遇到不同的问题，你会相信同样的问题重新出现并应用了一个糟糕的解决方案。
最好的办法是捕获糟糕的执行计划。 Showplan XML Event Class Profiler事件是您的朋友，您可以获得ADO.Net呼叫的计划。这是一个非常繁重的事件，因此您应该附加探查器并仅在问题在短时间内显现时捕获它。
查询IO统计信息也可以提供帮助。 RPC:Completed和SQL: Batch Completed事件都包含读取和写入，因此您可以比较ADO.Net调用与SSMS执行的逻辑IO数量。差异很大（对于完全相同的查询和参数）表示不同的计划。sys.dm_exec_query_stats是另一种调查途径。您可以在那里找到您的查询计划并检查执行统计数据。
如果问题是一个糟糕的计划或其他原因，所有这些都应该有助于确定。
答案 2 :(得分：2)
我一直有同样的问题。 我能解决这个问题的唯一方法是设置ARITHABORT ON。 但不幸的是，当它再次发生时我必须关闭ARITHABORT。
我不知道ARITHABORT与此有什么关系，但它有效，我已经有这个问题超过2年了，现在仍然没有解决方案。我正在使用的数据库超过300GB，所以这可能是一个尺寸问题......
我最接近解决此问题的方法来自之前的帖子 Google Groups post
如果您已经设法完全解决了这个问题，请告诉我，因为它非常令人沮丧！
答案 3 :(得分：0)
在系统忙于执行其他操作之后，您的ADO.NET查询是否可能正在运行，以便它所需的数据不再位于RAM中？当你在SSMS上测试时，它是？
您可以在运行查询之前通过从SSMS运行以下两个命令来检查：
CHECKPOINT
DBCC DROPCLEANBUFFERS
如果这导致SSMS查询运行缓慢，那么可以在ADO.NET端运行一些技巧来帮助它更快地运行。
答案 4 :(得分：0)
Simon Sabin在“查询计划出错时”（http://sqlbits.com/Sessions/Event5/When_a_query_plan_goes_wrong）上有一个很棒的会议，讨论如何通过使用各种“优化”提示来解决这个问题，以帮助proc生成一个一致的计划，而不是使用默认参数嗅探。
但是我遇到了SSMS计划和ASP计划完全相同的问题和临时查询（不在proc中） - 聚集索引/表扫描 - 但ASP查询需要3分钟以上而不是1秒。 （在这种情况下，表扫描恰好是获取结果的一个不错的答案。）
有人想解释那个吗？