了解Azure SQL性能

Question

事实：

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

在此表上运行Count-query需要将近30分钟（！）才能完成。

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

查看Azure门户（新版本）资源使用情况监视器显示以下内容：

问题：

1. 是否还有其他人认为13分钟为简单COUNT（）的rediculos？
2. 第二个截图是否在100％-period我的实例中没有响应其他请求？
3. 为什么我的指标在S0和S1都限制为100％？ （请参阅look under "Which Service Tier is Right for My Database?"说明＆＃34;这些值可以超过100％（相对于预览中最多100个值的重大改进）。＆＃34;）我期待如果引用的陈述是真的，那么S0就好于150％左右。

我对使用其他人超过1.000条记录的数据库的经验感兴趣。我不知道S * -scaled Azure SQL每月22-55欧元如何帮助我提升目前的升级策略。

Answer 1

Azure SQL数据库版本提供了来自Basic的增加级别的DTU - ＆gt;标准 - ＆gt;高级级别（CPU，IO，内存和其他资源 - 请参阅https://msdn.microsoft.com/en-us/library/azure/dn741336.aspx）。一旦您的查询在任何这些资源维度中达到DTU（100％）的限制，它将继续在该级别（但不是更多）接收这些资源，这可能会增加完成请求的延迟。看起来在上面的场景中，查询达到了DTU限制（S0为10 DTU，S1为20 DTU）。您可以通过将这些指标添加到同一图表中，或通过查询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版本不同，这为您的数据库提供了可预测的，有保证的资源量，根据在同一台计算机上运行的其他竞争客户数据库工作负载，您可能会在不同时间获得非常少或更多的资源。

希望这会有所帮助。 - Srini