简单选择计数（id）使用100％的Azure SQL DTU-Java 学习之路

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

基本上，运行：

select count(id) from mytable

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

需要在8到30之间运行 minutes （而SQL Server本地副本上的相同查询大约需要4 seconds ） .

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

enter image description here

一些额外的东西：

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

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

3 回答

3
从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.

您还应该发现重复扫描一半表会导致快速查询，因为分配的缓冲池似乎适合表的大部分（只是不是全部） .
回复于 2024-05-02T07:37:58+08:00
-1
我遇到过同样的问题 . 使用表上的fullscan更新统计信息解决了这个问题：
```
update statistics mytable with fullscan
```
回复于 2024-05-02T07:37:58+08:00
0

选择计数

应该执行聚簇索引扫描（如果有）并且是最新的 . 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

回复于 2024-05-02T07:37:58+08:00

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

3 回答

相关问题