Azure SQL查询编辑器vs Management Studio

Question

一般而言，我对天青和云计算还很陌生，想请您帮忙解决问题。

当我们将网页由于sql超时设置为（30秒）而超时时，首次发现该问题。

我所做的第一件事是使用MS SQL Management Studio 2014连接到生产数据库（已连接到Azure Prod数据库）

运行性能低下的页面正在使用的存储过程，但返回少于0秒。 这使我感到困惑，因为可能是引起该问题的原因。

偶然地，我也尝试在Azure SQL查询编辑器中运行相同的查询，但震惊的是它花了29秒来运行它。

我的主要问题是，为什么在Azure SQL查询编辑器中运行查询与Management Studio之间会有区别？ 这是完全相同的数据库。

DTU的使用率为98％，并且存储的过程存在性能问题，但首先想知道为什么sql editor运行SP的速度比Management Studio慢。

当前的天蓝色db有50 dtu。

Answer 1

两个猜想（发布查询计划将帮助您为此类情况提供答案）：

1. SQL Server具有各种会话级设置。 例如，可以使用一种方法来确定是否应使用ansi_nulls行为（相对于SQL Server的较旧版本中的先前设置）。 还有其他关于如何引用标识符和类似标识符的方法。 由于遗留原因，某些驱动程序具有不同的默认设置。 这些不同的设置可能会影响选择的查询计划。 尽管它们并不总是会影响性能，但是您有可能获得扫描而不是寻找您感兴趣的查询。

2. 解释此类问题的另一种主要途径是您有一个参数嗅探差异。 SQL的优化器将窥视用于选择更好计划的参数值（希望该值代表将来参数值的平均用例）。 Oracle将此称为绑定窥视-SQL将其称为参数嗅探。 这是我前一段时间在此发表的帖子，其中包含一些示例： https : //blogs.msdn.microsoft.com/queryoptteam/2006/03/31/i-smell-a-parameter/

我建议您进行实验，然后查看查询存储以查看是否有不同的查询或不同的计划被选择。 您可以在此处了解查询存储和SSMS UI： https ://docs.microsoft.com/zh-cn/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store?view = SQL服务器-2017

对于这种特定情况，请注意查询存储使用“上下文设置”公开那些不同的会话级设置。 上下文设置的每个唯一组合将显示为不同的上下文设置id，这将通知如何解释查询文本。 用查询存储的说法，可以在不同的上下文设置下以不同的方式解释相同的查询文本，因此同一查询文本的两个不同的上下文设置将意味着两个语义上不同的查询。

希望对您有帮助-最好解决您的性能问题