我有一个来自网站的查询需要 15-30 秒，而从 SQL Server Management studio 运行相同的查询只需 0.5 秒。我无法使用 SQL Profiler 查看任何锁定问题，也无法从 SSMS 手动重现延迟。一周前，我分离并重新连接了数据库，这似乎奇迹般地解决了问题。今天，当问题再次出现时，我只是尝试重建索引。这也解决了这个问题。但是，据我所知，我认为这不一定是索引问题，因为简单的分离/附加不会自动重建索引。
知道什么可能导致延迟吗？我的第一个想法是，也许对被调用的存储过程的某些参数嗅探(如果这很重要的话，存储过程运行 CTE)会导致错误的查询计划，这可以解释问题的间歇性。由于分离/重新附加和索引重建理论上应该使缓存的查询计划无效，这是有道理的，但我不确定如何验证这一点。此外，为什么相同的查询(使用完全相同的参数直接从 SQL Profiler 复制)在通过 SSMS 手动运行时不会表现出相同的延迟？
有什么想法吗？
最佳答案
我知道我很晚才开始讨论这个话题，但我想发布一个在遇到类似问题时找到的解决方案。简而言之，在我的过程开始时添加 SET ARITHABORT ON 命令使网站查询性能与 SQL Server 工具看到的性能一致。当您从 QA 或 SSMS 运行查询时，通常会在连接上设置此选项(您可以更改该选项，但它是默认选项)。
就我而言，我有大约 15 个不同的存储过程对相当大的数据集(数千行的 10 到 100 行)进行数学聚合(SUM、COUNT、AVG、STDEV) - 添加 SET ARITHABORT ON 选项它们的运行时间都从 3-5 秒缩短到 20-30 毫秒。
所以，希望这对其他人有帮助。
关于asp.net - SQL Server 查询在 ADO.NET 中的运行速度比在 SSMS 中慢，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1750369/