一般来说，我对Azure和云计算还很陌生，想请您帮忙解决问题。
当我们的网页由于sql超时设置为（30秒）而超时时，该问题首次出现。
我要做的第一件事是使用MS SQL Management Studio 2014连接到生产数据库（连接到Azure产品数据库）
运行性能不佳的页面正在使用的存储过程，但返回的时间少于0秒。这让我感到困惑，因为可能是引起问题的原因。
偶然地，我也尝试在Azure SQL查询编辑器中运行相同的查询，但震惊的是它花了29秒来运行它。
我的主要问题是，为什么在Azure SQL查询编辑器中运行查询与Management Studio之间会有区别？这是完全相同的数据库。
DTU的使用率达到98％，并且存储的过程存在性能问题，但首先想知道为什么sql editor运行SP的速度比Management Studio慢。
当前的天蓝色数据库有50 dtu。
答案 0 :(得分：0)
两个猜测（发布查询计划将为您提供类似情况的答案）
SQL Server具有各种会话级设置。例如，可以使用一种方法来确定是否应使用ansi_nulls行为（相对于SQL Server的较旧版本中的先前设置）。还有其他关于如何引用标识符和类似标识符的方法。由于遗留原因，某些驱动程序具有不同的默认设置。这些不同的设置可能会影响选择的查询计划。尽管它们并不总是会影响性能，但是您有机会获得扫描而不是寻找您感兴趣的查询。
解释此类问题的另一种主要途径是您有一个参数嗅探差异。 SQL的优化器将窥视用于选择更好计划的参数值（希望该值代表将来参数值的平均用例）。 Oracle将此称为绑定窥视-SQL将其称为参数嗅探。这是我前一段时间在此发表的帖子，其中列举了一些示例： https://blogs.msdn.microsoft.com/queryoptteam/2006/03/31/i-smell-a-parameter/
我建议您进行实验，然后查看查询存储以查看是否有不同的查询或不同的计划被选择。您可以在此处了解查询存储和SSMS UI： https://docs.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store?view=sql-server-2017
对于这种特定情况，请注意，查询存储使用“上下文设置”公开了这些不同的会话级设置。上下文设置的每个唯一组合将显示为不同的上下文设置id，这将通知如何解释查询文本。用查询存储的说法，可以在不同的上下文设置下以不同的方式解释相同的查询文本，因此同一查询文本的两个不同的上下文设置将意味着两个语义上不同的查询。
希望有帮助-最好能解决性能问题