Question

我有一个问题，希望你能帮忙。

使用VS 2013和SSMS开发vb.net Web应用程序。我有一个存储过程，在SSMS中测试时运行得非常快。但是，当我在Visual Studio中运行执行查询时，它需要永远，然后超时。

我尝试过的方法：确保它不是连接相关问题等等...我创建了一个带有相同输入参数的超级简单测试存储过程。我做的唯一代码更改来自＆＃34; StoredProcSlow＆＃34; to＆＃34; StoredProcTest＆＃34;。就是这样。这个代码在SSMS和Visual Studio中运行得非常好。所以，我知道vb.net代码很好。

请注意：两个存储过程的输入参数（原始和我的测试）完全相同。

我无法尝试使用分析器，因为我使用的是Azure SQL Server数据库。

任何想法可能是什么问题或我如何进一步排除故障？

更新：我将其缩小到存储过程中特定表的UPDATE。即使我进行虚拟更新，例如＆＃34; UPDATE dbo.Table1 SET DisplayName =＆＃39; XXXXX＆＃39; WHERE（DisplayName =＆＃39; XXXXX＆＃39;）＆＃34;它仍然挂起。禁用所有触发器。仍然挂起。任何想法都赞赏。

更新2：我将违规的Table1克隆到测试表（结构和数据）中。然后我在存储过程中使用了这个新的测试表。它跑得很好。这会让分钟更加混乱！

Answer 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数据库中使用，但基本概念适用。

在VB.net中存储过程超时但在SSMS中快速运行

1 个答案: