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 数据库具有严格的资源限制（正如我所听到和读到的），这会很快耗尽您购买的性能限制。

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