我们目前在 Azure 中有一个数据库弹性池，我们希望根据高 eDTU 使用率对其进行缩放。池中有 30+ 个数据库，它们目前使用 100GB 的存储空间(尽管这可能会增加)。
我们计划在检测到高 eDTU 使用率时增加分配给池的 eDTU。然而，网上的一些帖子让我质疑这将如何工作。以下引文摘自 azure 文档 - https://learn.microsoft.com/en-us/azure/sql-database/sql-database-resource-limits
重新缩放池 eDTU 的持续时间可能取决于池中所有数据库使用的存储空间总量。通常，重新缩放延迟平均为每 100 GB 90 分钟或更短。
如果我理解正确，这意味着如果我们想增加 eDTU，我们平均每 90GB 必须等待 100 分钟。如果是这种情况，动态扩展将不适合我们，因为等待性能提升的 90 分钟太长了。
谁能确认我上面所说的是否正确？是否有任何替代建议可以动态增加 eDTU，而不必等待这么长时间？
这也意味着，如果我们想根据时间表进行扩展，即在上午 8 点纵向扩展 eDTU，我们实际上必须在上午 6：30 启动扩展，以允许估计的 90 分钟扩展时间 - 如果我对此的理解是正确的。
缩放池 eDTU 时，Azure 可能必须迁移数据(这是一项共享数据库服务)。如果需要，这将需要时间。我已经看到扩展是即时的，我看到它需要很多时间。我认为Microsoft的目的是通过弹性池节省成本，而不是通过快速更改 eDTU 的能力。
以下是 Microssoft Azure SQL 数据库管理器提供的答案：
若要在同一层中重新缩放基本/标准池，某些服务 进行了优化，因此重新缩放延迟现在 通常与池中的数据库数成正比，并且 与其存储大小无关。 通常，延迟约为 每个数据库 30 秒，最多可并行提供 8 个数据库 池利用率不太高，运行时间不长 交易。 例如，包含 500 个数据库的标准池 无论大小如何，通常都可以在大约 30+ 分钟内重新缩放(即 ~ 500 个数据库 * 30 秒/8 个数据库并行)。
对于高级池，重新缩放延迟仍为 与数据大小成正比。
这位 Azure SQL 数据库管理器承诺，一旦他们完成实施更多改进，就会更新 Azure 文档。
感谢您耐心等待此答案。