当单个Azure SQL数据库升级到(S1->S3、S7->S9、P2->P4等(而没有其他更改(没有代码部署，没有负载更改(时，DTU百分比会降低，这是意料之中的。什么可以解释DTU百分比在转移到更高级别时增加，然后在降级到更小级别时又减少？
换句话说，通常可以预期P2 @ ~80%变成P4 @ ~40%。可以解释P2 @ ~80%在稳定负载、没有代码更改和没有增加的情况下变成P4 @ ~90%的原因是数据库大小(数据库读写繁重(更新，插入次数不多(。
例如，当有更多的DTU可用时，Query Store会变得更忙吗？
请注意，这不是在优化该数据库之后(这项工作正在完成，但这不是这个问题的一部分(
当您增加DTU时，事务日志吞吐量也会增加。
由于您的数据库具有沉重的UPDATE负载，因此在较低级别，您的写入可能会受到严重限制，并且您的CPU和内存开销接近MAX>
增加您的DTU允许您有更多的CPU和内存余量，但您的吞吐率可能仍因大量的更新而受到抑制。
用于avg_dto_percent的公式是avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)，因此，您可以看到，如果仅大量使用其中一种资源类型，则dtu仍然可能显示为高。
为了跟踪更详细的使用情况信息，sys.dm_db_resource_stats动态管理视图(DMV(允许您查看最后一小时的资源消耗情况。sys.resource_stats目录视图显示过去14天的资源消耗，但保真度较低，平均为5分钟。