小编ksp*_*rin的帖子

我在 S2 版本 (50 DTU) 下运行 Azure SQL 数据库。正常使用服务器通常会挂在10%左右的DTU。但是，此服务器会定期进入一种状态，它将在数小时内将数据库的 DTU 使用率发送到 85-90%。然后突然间它恢复到正常的 10% 使用率。

在这种过载状态下，应用程序对服务器的查询似乎仍在快速运行。

我可以从 S2 => 任何东西（例如 S3） => S2 扩展服务器，它似乎清除了它挂在的任何状态。但是几个小时后它会再次重复相同的过载状态循环。我注意到的另一件奇怪的事情是，如果我在 S3 计划 (100 DTU) 24/7 上运行此服务器，我没有观察到这种行为。只有当我将数据库缩小到 S2 计划 (50 DTU) 时才会出现这种情况。在 S3 计划中，我始终保持 5-10% 的 DTU 使用率。显然没有得到充分利用。

我已经检查了 Azure SQL 查询报告以查找恶意查询，但我并没有真正看到任何异常，它显示我的查询使用资源，正如我所期望的那样。

正如我们在这里看到的，使用量都来自数据 IO。如果我在此处更改性能报告以显示 MAX 的顶级数据 IO 查询，我们会看到：

查看这些长期运行的查询似乎指向统计更新。并不是真正从我的应用程序运行的任何东西。例如，查询 16302 显示：

SELECT StatMan([SC0], [SC1], [SC2], [SB0000]) FROM (SELECT TOP 100 PERCENT [SC0], [SC1], [SC2], step_direction([SC0]) over (order by NULL) AS [SB0000]  FROM (SELECT [UserId] AS [SC0], [OrganizationId] AS …

我有一个支持 .NET Core API 应用程序的 Azure SQL 数据库。浏览 Azure 门户中的性能概览报告表明，我的数据库服务器上的大部分负载（DTU 使用情况）来自 CPU，特别是一个查询：

正如我们所见，查询 3780 负责几乎所有服务器上的 CPU 使用率。

这在某种程度上是有道理的，因为查询 3780（见下文）基本上是整个应用程序的关键，并且经常被用户调用。这也是一个相当复杂的查询，需要许多连接才能获得所需的正确数据集。查询来自一个最终看起来像这样的 sproc：

-- @UserId UNIQUEIDENTIFIER

SELECT
    C.[Id],
    C.[UserId],
    C.[OrganizationId],
    C.[Type],
    C.[Data],
    C.[Attachments],
    C.[CreationDate],
    C.[RevisionDate],
    CASE
        WHEN
            @UserId IS NULL
            OR C.[Favorites] IS NULL
            OR JSON_VALUE(C.[Favorites], CONCAT('$."', @UserId, '"')) IS NULL
        THEN 0
        ELSE 1
    END [Favorite],
    CASE
        WHEN
            @UserId IS NULL
            OR C.[Folders] IS NULL
        THEN NULL
        ELSE TRY_CONVERT(UNIQUEIDENTIFIER, JSON_VALUE(C.[Folders], CONCAT('$."', @UserId, '"')))
    END [FolderId],
    CASE 
        WHEN C.[UserId] IS NOT NULL OR …