了解 Azure SQL 性能

Question

事实：

• 1 个 Azure SQL S0 实例
• 几个表，其中一个包含约 860 万行和 1 个 PK

在此表上运行计数查询需要近 30 分钟 (!) 才能完成。

将实例从 S0 升级到 S1 可将查询时间缩短至 13 分钟：

查看 Azure 门户（新版本），resource-usage-monitor 显示以下内容：

问题：

1. 对于简单的 COUNT()，是否有其他人认为即使 13 分钟也是 rediculos？
2. 第二个屏幕截图是否意味着在 100% 期间我的实例没有响应其他请求？
3. 为什么我的指标在 S0 和 S1 中都限制为 100%？ （请参阅look under "Which Service Tier is Right for My Database?" 声明“这些值可以高于 100%（对预览中限制为最大值 100 的值有很大改进）。”）我希望 S0 会像蜜蜂一样达到 150% 左右如果引用的陈述为真。

我对使用具有超过 1000 条记录的数据库的经验感兴趣。目前，我不知道每月 22 到 55 欧元的 S* 规模 Azure SQL 对我的升级策略有何帮助。

Answer 1

Azure SQL 数据库版本提供从基本 -> 标准 -> 高级级别（CPU、IO、内存和其他资源 - 请参阅 https://msdn.microsoft.com/en-us/library/azure/dn741336.aspx）不断增加的 DTU 级别。一旦您的查询在任何这些资源维度中达到其 DTU (100%) 限制，它将继续在该级别（但不是更多）接收这些资源，这可能会增加完成请求的延迟。看起来在上面的场景中，查询达到了 DTU 限制（S0 为 10 个 DTU，S1 为 20 个）。您可以通过将这些指标添加到同一图表或查询 DMV sys.dm_db_resource_stats 来查看各个资源使用百分比（CPU、数据 IO 或日志 IO）。

这是一个博客，提供了有关适当调整数据库性能级别的更多信息。 http://azure.microsoft.com/blog/2014/09/11/azure-sql-database-introduces-new-near-real-time-performance-metrics/

针对您的具体问题

1) 由于您有 860 万行，数据库需要扫描索引条目以获取计数。所以，这里可能会达到版本的 IO 限制。

2) 如果您有多个并发查询对您的数据库运行，它们将被适当地安排，不会饿死一个请求或另一个。但所有查询的延迟可能会进一步增加，因为您将达到可用资源限制。

3) 对于较旧的 Web/Business 版本，您可能会看到超过 100% 的指标值（它们被标准化为 S2 级别的限制），因为它们没有任何特定限制并且在与其他客户负载的资源共享环境。对于新版本，指标永远不会超过 100%，因为系统保证您的资源达到该版本限制的 100%，但仅此而已。这为您的数据库提供了可预测的、有保证的资源量，这与 Web/Business 版本不同，在 Web/Business 版本中，您可能会在不同时间获得很少或更多的资源，具体取决于在同一台机器上运行的其他竞争客户数据库工作负载。

希望这会有所帮助。 -- 斯里尼