sql-server - Azure SQL 数据库 DTU 已满 - 由于数据库较大？

Question

我们有一个 Azure SQL 数据库。直到几周前，我们还设置为 10 个 DTU (S0)。最近，我们收到了更多 SQL 超时错误，促使我们将 DTU 增加到 50 (S2)。我们遇到错误的频率较低，但偶尔也会出现。当我们遇到这些超时时，我们会看到资源图上的峰值达到 100%。深入研究一下，通常是数据 I/O 操作导致了峰值。但是，当我们检查 Query Performance Insight 时，所列出的查询均未显示它们正在使用那么多资源。

另一件值得注意的事情是我们的数据库规模一直在稳步增长。现在约为 19 GB，其中大部分 (18 GB) 来自一个包含大量长 JSON 字符串的表。超时错误通常发生在具有多个连接的特定查询上，但它们不会与具有长字符串的表交互。

我们测试了制作数据库的副本并删除所有长字符串，它在 10 DTU 时没有出现任何超时，但就加载时间而言，其性能与具有所有长字符串的数据库在 50 DTU 时相同。

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

鉴于超时的查询并未触及具有长字符串的表，那么具有长字符串的表是否仍然是 DTU 使用的罪魁祸首？与 SQL 缓存有关吗？长字符串是否会占用缓存并导致大量数据 I/O？ (它们的访问也相当频繁。)

Answer 1

如果字符串很热(正如您所说)，它们肯定会耗尽您的缓存预算。当热工作集超过 RAM 缓存大小时，性能可能会急剧下降 (10-100 倍)。这是因为 IO 比 RAM 访问慢 10-1000 倍。这意味着，即使缓存命中率略有下降(例如 1%)，也会造成巨大的性能损失。

这个悬崖可能非常陡峭。某一时刻应用还不错，下一时刻 IO 就破纪录了。

由于 Azure SQL 数据库具有严格的资源限制(正如我所听到和读到的)，这会很快耗尽您购买的性能，从而带来限制。

我认为您所做的测试证实了字符串导致了问题。您可以尝试将字符串隔离在其他地方吗？如果它们冷了，就把它们移到另一张 table 上。如果它们很热，请将它们移动到另一个数据存储(数据库或 NoSQL)。这样您就可以回到更低的级别。