我有一个网站的查询需要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是另一个调查渠道.您可以在其中找到您的查询计划并检查执行统计信息.
所有这些都应该有助于确定问题是否是一个坏的计划或别的东西,首先.
