asp.net – SQL Server查询从ADO.NET运行速度比SSMS慢

发布时间：2020-12-15 20:40:44 所属栏目：asp.Net 来源：网络整理

导读：我有一个网站的查询需要15-30秒的时间,同样的查询在.5秒内运行SQL Server Management studio.使用SQL Profiler不能看到任何锁定问题,也不能从SSMS手动重现延迟.一个星期前,我分离并重新连接数据库,这似乎奇迹般地解决了这个问题.今天,当这个问题再次丑陋的时

我有一个网站的查询需要15-30秒的时间,同样的查询在.5秒内运行SQL Server Management studio.使用SQL Profiler不能看到任何锁定问题,也不能从SSMS手动重现延迟.一个星期前,我分离并重新连接数据库,这似乎奇迹般地解决了这个问题.今天,当这个问题再次丑陋的时候,我只想重建索引.这也解决了这个问题.但是,我认为这不一定是一个索引问题,因为索引不会自动重建在一个简单的分离/附加,据我所知.

有什么想法可能导致延误？我的第一个想法是,可能有一些参数嗅探存储过程被调用(所述存储过程运行CTE,如果重要)导致了一个坏的查询计划,这将解释问题的间歇性质.由于分离/重新连接和索引重建在理论上应该使缓存的查询计划无效,这是有道理的,但我不确定如何验证这一点.此外,为什么不通过SSMS手动运行相同的查询(直接从具有完全相同参数的SQL Profiler复制)的查询显示相同的延迟？

有什么想法吗？

解决方法

如果一个坏的计划被缓存,那么SSMS也应该使用同样的坏的计划,如果你运行的是相同参数的查询.

找不到根本原因不能有更好的解决方案.试图偷看和戳捅各种设置,希望它修复问题永远不会给你实际确定的信心.此外,下一次系统可能会有一个不同的问题,你会相信这个同样的问题重新出现,并应用一个坏的解决方案.

最好的尝试是捕获坏的执行计划. Showplan XML Event Class Profiler事件是您的朋友,您可以获得ADO.Net电话的计划.这是一个非常重的事件,所以你应该附加分析器,并捕获它只有当问题出现在一个简短的会话.

查询IO统计信息也可以帮助. RPC:Completed和SQL: Batch Completed事件都包括读取和写入,因此您可以比较由ADO.Net调用与SSMS一个执行的逻辑IO的数量.大差异(完全相同的查询和参数)表示不同的计划.7003是另一个调查渠道.您可以在其中找到您的查询计划并检查执行统计信息.

所有这些都应该有助于确定问题是否是一个坏的计划或别的东西,首先.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!