简单选择计数（id）使用100％的Azure SQL DTU

Question

这开始于this question，但现在看起来更合适，因为我意识到这是与DTU相关的问题。

基本上，跑步：

select count(id) from mytable

编辑：添加where子句似乎没有帮助。

需要8到30 分钟才能运行（而SQL Server本地副本上的相同查询大约需要4 秒）。

下面是运行此查询时Azure门户中MONITOR选项卡的屏幕截图。注意我在没有触及数据库大约一周后执行此操作，Azure报告我只使用了1％的DTU。

一些额外的东西：

• 在此特定测试中，查询运行时间为08:27。
• 当它运行时，上面的图表实际上显示DTU线在一段时间内处于100％。
• 数据库配置标准服务层，具有S1性能级别。
• 数据库大约是3.3GB，这是最大的表（计数返回大约2,000,000）。

我很欣赏它可能只是我有限的理解，但是如果有人能够澄清这是否真的是预期的行为（即一个简单的计算需要花费很长时间才能运行并最大化我的DTU），我们将非常感激。

Answer 1

根据previous question中的查询统计信息，我们可以看到：

300ms CPU time
8000 physical reads

8:30是大约500秒。我们当然不受CPU限制。超过500秒的300毫秒CPU几乎没有利用率。我们每秒获得16次物理读取。这远低于任何物理磁盘所能提供的功能。此外，表格未完全缓存，如物理IO的存在所证明。

我说你被扼杀了。 S1 corresponds到

  

每分钟934笔交易

用于某种交易定义。多达15转/秒。也许你每次交易都达到了一个物理IO的限制？！ 15和16是可疑的相似数字。

通过将实例升级到更高的比例因子来测试此理论。 You might find that SQL Azure Database cannot deliver the performance you want at an acceptable price.

您还应该发现重复扫描表的 half 会导致快速查询，因为分配的缓冲池似乎适合表的大部分（只是不是全部）。

Answer 2

我有同样的问题。使用表格中的fullscan更新统计数据解决了这个问题：

update statistics mytable with fullscan

Answer 3

选择计数

应执行聚簇索引扫描（如果有）并且是最新的。 Azure SQL应自动更新统计信息，但如果索引完全过期，则不会自动重建索引。

如果该表上有很多INSERT / UPDATE / DELETE流量，我建议每隔一段时间手动重建一次索引。

http://blogs.msdn.com/b/dilkushp/archive/2013/07/28/fragmentation-in-sql-azure.aspx

和SO帖子了解更多信息

SQL Azure and Indexes