Azure SQL数据库的DTU达到极限 - 是因为数据库太大了吗？

Question

我们有一个Azure SQL数据库。直到几周前，我们设置的DTU为10（S0）。最近，我们遇到了更多的SQL超时错误，促使我们将DTU增加到50（S2）。我们收到的错误不那么频繁，但偶尔仍然会出现。当我们遇到这些超时时，我们会看到资源图上的峰值达到100%。进一步分析发现，通常是数据I/O操作导致峰值。但是当我们检查查询性能洞察时，没有列出的查询显示它们使用了那么多的资源。

另一个需要注意的事项是我们的数据库大小稳步增长。现在大约为19 GB，其中大部分（18 GB）来自一个包含很多长JSON字符串的表。超时错误通常发生在一个具有多个连接的特定查询上，但它们不与包含长字符串的表进行交互。

我们测试了复制数据库并删除所有长字符串，结果在10 DTU时没有任何超时，在50 DTU下的负载时间与包含所有长字符串的数据库相同。

我们已经重建了索引，虽然有所帮助，但仍然遇到超时错误。

鉴于超时查询未涉及包含长字符串的表，长字符串的表是否仍可能是DTU使用量的罪魁祸首？是否与SQL缓存有关？长字符串是否占用缓存并导致大量数据I/O？（它们也相当频繁地被访问。）

- Scotty H

Answer 1

字符串如果是热数据，它们肯定会耗尽缓存预算。当热工作集超过 RAM 缓存大小时，性能会急剧下降（10-100倍）。这是因为 IO 访问速度比 RAM 慢 10-1000 倍。这意味着即使缓存命中率稍微降低一点（例如 1%），也可能导致大量的性能损失。

这个性能下降非常陡峭。应用程序一会儿正常，下一刻 IO 就会突然飙升。

由于 Azure SQL 数据库有严格的资源限制（据我所听和所读），这可能会迅速耗尽你购买的性能，从而导致限流。

我认为你做的测试证实了字符串是造成问题的原因。你可以尝试将字符串隔离到其他地方吗？如果它们是冷数据，请将它们移动到另一个表中。如果它们是热数据，请将它们移动到另一个数据存储区（数据库或 NoSQL）。这样，你就可以回到更低的层级。

- usr