我有一个问题,希望你能帮忙。
使用VS 2013和SSMS开发vb.net Web应用程序。我有一个存储过程,在SSMS中测试时运行得非常快。但是,当我在Visual Studio中运行执行查询时,它需要永远,然后超时。
我尝试过的方法:确保它不是连接相关问题等等...我创建了一个带有相同输入参数的超级简单测试存储过程。我做的唯一代码更改来自" StoredProcSlow" to" StoredProcTest"。就是这样。这个代码在SSMS和Visual Studio中运行得非常好。所以,我知道vb.net代码很好。
请注意:两个存储过程的输入参数(原始和我的测试)完全相同。
我无法尝试使用分析器,因为我使用的是Azure SQL Server数据库。
任何想法可能是什么问题或我如何进一步排除故障?
更新:我将其缩小到存储过程中特定表的UPDATE。即使我进行虚拟更新,例如" UPDATE dbo.Table1 SET DisplayName =' XXXXX' WHERE(DisplayName =' XXXXX')"它仍然挂起。禁用所有触发器。仍然挂起。任何想法都赞赏。
更新2:我将违规的Table1克隆到测试表(结构和数据)中。然后我在存储过程中使用了这个新的测试表。它跑得很好。这会让分钟更加混乱!
答案 0 :(得分:1)
性能差异很大的原因可能是不同的执行计划。运行下面的查询以查看是否有多个缓存计划用于同一个proc:
SELECT qs.plan_handle
, qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) est
OUTER APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp
WHERE est.objectid = OBJECT_ID('dbo.your_proc');
由于会话设置不同,可能存在多个计划。 SQL Server联机丛书(https://msdn.microsoft.com/en-us/library/ms189472.aspx)中描述了组成密钥的属性。
有关此主题的详尽讨论,请参阅Erland Sommarskog文章:http://www.sommarskog.se/query-plan-mysteries.html。请注意,并非本文中引用的所有DMV都可在Azure SQL数据库中使用,但基本概念适用。