azure - 了解 Azure SQL 性能

Question

事实:

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

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

将实例从 S0 升级到 S1 将查询时间减少到 13 分钟:

查看 Azure 门户(新版本)，资源使用监视器显示以下内容:

问题:

1. 还有人认为对于一个简单的 COUNT() 来说，即使 13 分钟也是累赘吗？
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 数据库版本提供的 DTU 级别不断增加，从基本 -> 标准 -> 高级级别(CPU、IO、内存和其他资源 - 请参阅 https://msdn.microsoft.com/en-us/library/azure/dn741336.aspx)。一旦您的查询达到任何这些资源维度中的 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/商业版本，您可能会看到超过 100% 的指标值(它们已标准化为 S2 级别的限制)，因为它们没有任何特定限制并在与其他客户负载共享资源的环境。对于新版本，指标永远不会超过 100%，因为系统保证您的资源最多为该版本限制的 100%，但不会更多。这为您的数据库提供了可预测的、有保证的资源量，与 Web/商业版本不同，在 Web/商业版本中，您可能会在不同时间获得很少或更多的资源，具体取决于同一台计算机上运行的其他竞争客户数据库工作负载。

希望这有帮助。——斯里尼