Azure SQL 查询编辑器与 Management Studio答案

【问题标题】：Azure SQL Query Editor vs Management StudioAzure SQL 查询编辑器与 Management Studio
【发布时间】：2019-04-02 04:05:45
【问题描述】：

总的来说，我对 Azure 和云计算还很陌生，想请你帮忙解决问题。

当我们的网页由于 sql 超时设置为（30 秒）而超时时，第一次发现此问题。

我做的第一件事是使用 MS SQL 管理工作室 2014 连接到生产数据库（连接到 azure prod db）

运行低性能页面正在使用的存储过程，但返回不到 0 秒。这让我很困惑，因为可能是什么导致了这个问题。

意外地，我也尝试在 Azure SQL 查询编辑器中运行相同的查询，但运行它需要 29 秒，这让我感到震惊。

我的主要问题是为什么在 azure sql 查询编辑器和 Management Studio 中运行查询之间存在差异。这是完全相同的数据库。

DTU 使用率为 98%，我认为存储过程存在性能问题，但首先想知道为什么 sql 编辑器运行 SP 的速度比 Management Studio 慢。

当前 azure db 有 50 个 dtu。

【问题讨论】：

听起来像参数嗅探。我不敢相信它仍然是一件事！
@Nick.McDermaid 我目前正在阅读有关参数嗅探的信息并考虑其影响，但问题仍然存在，如果存在参数嗅探问题，为什么在我使用管理工作室时不会发生？您是说嗅探是在客户端而不是在实际服务器中完成的吗？我们说的是同一台服务器，只是不同的客户端
我发现不同的客户端（库）使用不同的 SET 设置。因此，从 EF 运行的查询使用与从 SSMS 运行的查询不同的 SET ARITHABORT。这意味着整个查询获得不同的“指纹”，这意味着它使用不同的（可能是新的）缓存查询计划。参数嗅探是关于使用错误的缓存查询计划，这通常是由于初始参数集错误。我希望这是有道理的。
您的网络应用使用什么 DAL？英孚？因为通常的事件顺序是使用 EF 的应用程序很慢，然后您在 SSMS 中运行它并且它很快。再次 - 通过参数嗅探，它不是真正的客户端或库，只是它们使用稍微不同的 SET 设置，为查询提供新指纹并强制执行新计划

【解决方案1】：

两种猜测（发布查询计划将帮助您回答此类情况）：

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，这将告知如何解释查询文本。在查询存储用语中，相同的查询文本可以在不同的上下文设置下以不同的方式解释，因此相同查询文本的两个不同上下文设置将意味着两个语义不同的查询。

希望对您有所帮助 - 祝您在性能问题上好运

【讨论】：

我正在查看给出的数据，但由于一位用户所做的编辑，我不确定问题是否明确。这是我们正在谈论的同一个数据库。如果它是一个参数嗅探问题，我将使用哪个客户端应用程序连接是否重要？它是相同的天蓝色数据库和相同的过程。
对于来自不同客户端的相同命令，参数嗅探通常与客户端无关。但是，根据您使用的客户端，可能会有不同的行为。您必须检查提交了哪些查询/计划。（您可以使用查询存储进行验证）。